Date: Sun, 9 Oct 2011 06:46:06 -0700 From: Jeremy Chadwick <freebsd@jdc.parodius.com> To: V??clav Zeman <v.haisman@sh.cvut.cz> Cc: freebsd-stable@freebsd.org Subject: Re: valgrind on FreeBSD? Message-ID: <20111009134606.GA44304@icarus.home.lan> In-Reply-To: <4E91A0C3.7030305@sh.cvut.cz> References: <4E8CC6BC.9040605@sh.cvut.cz> <20111006064038.CFB34B852@mail.bitblocks.com> <4E91A0C3.7030305@sh.cvut.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
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==?= <v.haisman@sh.cvut.cz> 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,<unused>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,<unused>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 |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111009134606.GA44304>