From owner-freebsd-stable@FreeBSD.ORG Sun Oct 9 13:46:09 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DADCF106564A for ; Sun, 9 Oct 2011 13:46:09 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by mx1.freebsd.org (Postfix) with ESMTP id 882248FC12 for ; Sun, 9 Oct 2011 13:46:09 +0000 (UTC) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta01.westchester.pa.mail.comcast.net with comcast id ic2e1h0031c6gX851dm9jb; Sun, 09 Oct 2011 13:46:09 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta23.westchester.pa.mail.comcast.net with comcast id idm71h00M1t3BNj3jdm859; Sun, 09 Oct 2011 13:46:09 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 190DB102C1C; Sun, 9 Oct 2011 06:46:06 -0700 (PDT) Date: Sun, 9 Oct 2011 06:46:06 -0700 From: Jeremy Chadwick To: V??clav Zeman Message-ID: <20111009134606.GA44304@icarus.home.lan> References: <4E8CC6BC.9040605@sh.cvut.cz> <20111006064038.CFB34B852@mail.bitblocks.com> <4E91A0C3.7030305@sh.cvut.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E91A0C3.7030305@sh.cvut.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: valgrind on FreeBSD? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2011 13:46:09 -0000 On Sun, Oct 09, 2011 at 03:25:23PM +0200, V??clav Zeman wrote: > Bakul Shah wrote, On 6.10.2011 8:40: > > On Wed, 05 Oct 2011 23:06:04 +0200 =?UTF-8?B?VsOhY2xhdiBaZW1hbg==?= wrote: > >> Hi. > >> > >> No matter what I try, valgrind on 7.3-STABLE is giving me this, both Valgrind > >> ports: > >> > >> valgrind: Startup or configuration error: > >> Can't establish current working directory at startup > >> valgrind: Unable to start up properly. Giving up. > >> > >> What do I need to do to make it work? > > > > Try running valgrind under ktrace (& view with kdump). That > > will tell you what directory it is trying to access or what > > syscall fails and why. > Hi. > > So I have done that and more. I have first updated from 7.3 to 8.2 (RELENG_8 > actually). I have not managed to recompile all of the installed Ports yet, > but I made sure to recompile valgrind and its dependencies. The same thing > has happened! > > As I have said, I have done the ktrace and here is the interesting bit: > > 78028 valgrind NAMI "/usr/local/lib/valgrind/memcheck-amd64-freebsd" > 78028 memcheck-amd64-free RET execve 0 > 78028 memcheck-amd64-free CALL getpid > 78028 memcheck-amd64-free RET getpid 78028/0x130cc > 78028 memcheck-amd64-free CALL > __sysctl(0x39a91450,0x4,0x389a3800,0x39a91468,0,0) > 78028 memcheck-amd64-free SCTL "kern.proc.vmmap.78028" > 78028 memcheck-amd64-free RET __sysctl 0 > 78028 memcheck-amd64-free CALL > mmap(0x400009000,0x400000,PROT_READ|PROT_WRITE|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_ANON,0xffffffffffffffff,0) > 78028 memcheck-amd64-free RET mmap 17179906048/0x400009000 > 78028 memcheck-amd64-free CALL getrlimit(RLIMIT_DATA,0x39e6a780) > 78028 memcheck-amd64-free RET getrlimit 0 > 78028 memcheck-amd64-free CALL setrlimit(RLIMIT_DATA,0x39a919e0) > 78028 memcheck-amd64-free RET setrlimit 0 > 78028 memcheck-amd64-free CALL getrlimit(RLIMIT_STACK,0x39e6a790) > 78028 memcheck-amd64-free RET getrlimit 0 > 78028 memcheck-amd64-free CALL __getcwd(0x3882d700,0x3ff) > 78028 memcheck-amd64-free NAMI ".." > 78028 memcheck-amd64-free RET __getcwd -1 errno 2 No such file or directory > 78028 memcheck-amd64-free CALL write(0x2,0x3830b060,0x6c) > 78028 memcheck-amd64-free GIO fd 2 wrote 108 bytes > "valgrind: Startup or configuration error: > valgrind: Can't establish current working directory at startup > " > 78028 memcheck-amd64-free RET write 108/0x6c > 78028 memcheck-amd64-free CALL write(0x2,0x3830b060,0x33) > 78028 memcheck-amd64-free GIO fd 2 wrote 51 bytes > "valgrind: Unable to start up properly. Giving up. > " > 78028 memcheck-amd64-free RET write 51/0x33 > 78028 memcheck-amd64-free CALL exit(0x1) > > Now what? Why would the __getcwd call be failing with "No such file or > directory"? I can't reproduce this problem on our RELENG_7 system (7.4-STABLE, though i386). Filesystem being accessed by valgrind is UFS2 + SU. $ valgrind /usr/local/bin/mysql ==47587== Memcheck, a memory error detector ==47587== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==47587== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info ==47587== Command: /usr/local/bin/mysql ==47587== Welcome to the MySQL monitor. Commands end with ; or \g. {snip} And this is what I see under "ktrace valgrind /usr/local/bin/mysql": 47590 memcheck-x86-freebs RET execve 0 47590 memcheck-x86-freebs CALL getpid 47590 memcheck-x86-freebs RET getpid 47590/0xb9e6 47590 memcheck-x86-freebs CALL __sysctl(0x3955b604,0x4,0x38473200,0x3955b62c,0,0) 47590 memcheck-x86-freebs SCTL "kern.proc.vmmap.47590" 47590 memcheck-x86-freebs RET __sysctl 0 47590 memcheck-x86-freebs CALL mmap(0x5fe08000,0x400000,PROT_READ|PROT_WRITE|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_ANON,0xffffffff,0 ,0) 47590 memcheck-x86-freebs RET mmap 1608548352/0x5fe08000 47590 memcheck-x86-freebs CALL getrlimit(RLIMIT_DATA,0x3984cf30) 47590 memcheck-x86-freebs RET getrlimit 0 47590 memcheck-x86-freebs CALL setrlimit(RLIMIT_DATA,0x3955bb98) 47590 memcheck-x86-freebs RET setrlimit 0 47590 memcheck-x86-freebs CALL getrlimit(RLIMIT_STACK,0x3984cf40) 47590 memcheck-x86-freebs RET getrlimit 0 47590 memcheck-x86-freebs CALL __sysctl(0x3955b62c,0x2,0x3955b604,0x3955b634,0x3818cab2,0x12) 47590 memcheck-x86-freebs SCTL "sysctl.name2oid" 47590 memcheck-x86-freebs RET __sysctl 0 47590 memcheck-x86-freebs CALL __sysctl(0x3955b604,0x2,0x3955b678,0x3955b674,0,0) 47590 memcheck-x86-freebs SCTL "hw.instruction_sse" 47590 memcheck-x86-freebs RET __sysctl 0 47590 memcheck-x86-freebs CALL __getcwd(0x38316fa0,0x3ff) 47590 memcheck-x86-freebs NAMI "/home/jdc" 47590 memcheck-x86-freebs RET __getcwd 0 47590 memcheck-x86-freebs CALL open(0x3955add0,O_RDONLY,0x100) 47590 memcheck-x86-freebs NAMI "/home/jdc/.valgrindrc" 47590 memcheck-x86-freebs RET open -1 errno 2 No such file or directory 47590 memcheck-x86-freebs CALL open(0x38e79260,O_RDONLY,0) 47590 memcheck-x86-freebs NAMI "/usr/local/bin/mysql" 47590 memcheck-x86-freebs RET open 3 47590 memcheck-x86-freebs CALL stat(0x38e79260,0x3955a2a4) {snip} I also tried doing: $ cd /usr/local/sbin $ ktrace -f /home/jdc/ktrace.out -t+ valgrind ../bin/mysql ==47645== Memcheck, a memory error detector ==47645== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==47645== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info ==47645== Command: ../bin/mysql ==47645== Welcome to the MySQL monitor. Commands end with ; or \g. {snip} You get the idea. Stuff I can think of: >From the same directory you ran valgrind above, please provide the output from commands "ls -ldoi ." and "ls -ldoi ..". Other relevant questions: * What filesystem type is associated with . and .. on the system? Be sure to note if softupdates are in use or not too. * Has this system crashed recently or even many months ago? * If so, did you run fsck manually from single-user rather than rely on background fsck? (There are confirmed cases of background fsck not fixing everything) * If not, have you actually tried booting single-user and running fsck to see if you have some filesystem corruption in some weird way? This is completely 100% possible. * Is this being run within a FreeBSD jail environment? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB |