valgrind on FreeBSD?
Václav Zeman
v.haisman at sh.cvut.cz
Sun Oct 9 13:54:56 UTC 2011
Jeremy Chadwick wrote, On 9.10.2011 15:46:
> 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 at 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.
/dev/ufs/usrvol on /usr (ufs, local, with quotas, soft-updates, multilabel, acls)
/usr/home on /home (nullfs, local)
> * Has this system crashed recently or even many months ago?
No, this system was up for 344 days before I updated from 7.3 to 8.2 yesterday.
> * 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)
I never run background fsck. The FSs are clean.
> * 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?
No jails here.
See my other email, it looks like the problem is the nullfs mount I have for
/home.
--
Vaclav Zeman
More information about the freebsd-stable
mailing list