valgrind on FreeBSD?
Václav Zeman
v.haisman at sh.cvut.cz
Sun Oct 9 14:19:15 UTC 2011
Jeremy Chadwick wrote, On 9.10.2011 16:11:
> On Sun, Oct 09, 2011 at 03:48:57PM +0200, V??clav Zeman wrote:
>> V??clav Zeman wrote, On 9.10.2011 15:25:
>>> 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"?
>>>
>> It is the nullfs!
>>
>> I have /home mounted using nullfs to /usr/home:
>>
>> /usr/home /home nullfs rw,multilabel,acls
>> 0 0
>>
>> When I run valgrind from the /usr based directory, it works:
>>
>> shell::wilx:/usr/home/users/wilx/tmp/yttool> valgrind --tool=memcheck ./yttool
>> ==34679== Memcheck, a memory error detector
>> ==34679== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
>> ==34679== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
>> ==34679== Command: ./yttool
>> ==34679==
>> ==34679==
>> ==34679== HEAP SUMMARY:
>> ==34679== in use at exit: 20,395 bytes in 119 blocks
>> ==34679== total heap usage: 6,719 allocs, 6,600 frees, 716,787 bytes allocated
>> ==34679==
>> ==34679== LEAK SUMMARY:
>> ==34679== definitely lost: 0 bytes in 0 blocks
>> ==34679== indirectly lost: 0 bytes in 0 blocks
>> ==34679== possibly lost: 134 bytes in 4 blocks
>> ==34679== still reachable: 20,261 bytes in 115 blocks
>> ==34679== suppressed: 0 bytes in 0 blocks
>> ==34679== Rerun with --leak-check=full to see details of leaked memory
>> ==34679==
>> ==34679== For counts of detected and suppressed errors, rerun with: -v
>> ==34679== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
>>
>> But when I run it from the nullfs mount, it fails:
>>
>> shell::wilx:/usr/home/users/wilx/tmp/yttool> cd $HOME/tmp/yttool
>> shell::wilx:~/tmp/yttool> valgrind --tool=memcheck ./yttool
>> valgrind: Startup or configuration error:
>> valgrind: Can't establish current working directory at startup
>> valgrind: Unable to start up properly. Giving up.
>
> Amazing how userland utilities behave differently depending upon the
> underlying filesystem type, eh? Good thing I asked what your underlying
> filesystem types were. Don't ever think that "it'll all just work".
> :-)
>
> I believe there are other issues/stipulations with nullfs (some have
> been reported over the years), so I'm not too surprised by this issue.
> I have no idea who currently maintains nullfs(5) either; it looks like a
> major group effort given the committers who have touched it in the past
> few years:
>
> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/fs/nullfs/
>
> I'm CC'ing Kostik (kib@) as he might have some ideas.
>
> If this isn't a known issue, please file a PR for the issue with
> nullfs(5). The issue is not within valgrind, so the PR should not be
> for that.
I have filled a PR: <http://www.freebsd.org/cgi/query-pr.cgi?pr=161424>
>
> As for a workaround: is there some reason you can't just use "ln -s
> /usr/home /home" and solve the problem?
None. I remember using nullfs for /home instead of the link because I just
liked that it never has shown /usr there and also because it seemed cooler. :)
--
VZ
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 292 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20111009/ce24a2bf/signature.pgp
More information about the freebsd-stable
mailing list