valgrind on FreeBSD?

Sun Oct 9 14:11:21 UTC 2011

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.

As for a workaround: is there some reason you can't just use "ln -s
/usr/home /home" and solve the problem?

-- 
| 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 |