Date: Sun, 9 Oct 2011 17:21:31 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: V??clav Zeman <v.haisman@sh.cvut.cz> Cc: freebsd-stable@freebsd.org Subject: Re: valgrind on FreeBSD? Message-ID: <20111009142131.GQ1511@deviant.kiev.zoral.com.ua> In-Reply-To: <4E91AD48.5070906@sh.cvut.cz> References: <4E8CC6BC.9040605@sh.cvut.cz> <20111006064038.CFB34B852@mail.bitblocks.com> <4E91A0C3.7030305@sh.cvut.cz> <4E91A649.5060207@sh.cvut.cz> <20111009141117.GA47243@icarus.home.lan> <4E91AD48.5070906@sh.cvut.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
--4qkYhMaAfKuF3v0Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 09, 2011 at 04:18:48PM +0200, V??clav Zeman wrote: > 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 =3D?UTF-8?B?VsOhY2xhdiBaZW1hbg=3D= =3D?=3D <v.haisman@sh.cvut.cz> wrote: > >>>>> Hi. > >>>>> > >>>>> No matter what I try, valgrind on 7.3-STABLE is giving me this, bot= h 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 (R= ELENG_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 bi= t: > >>> > >>> 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 sta= rtup > >>> " > >>> 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=3Dmemchec= k ./yttool > >> =3D=3D34679=3D=3D Memcheck, a memory error detector > >> =3D=3D34679=3D=3D Copyright (C) 2002-2010, and GNU GPL'd, by Julian Se= ward et al. > >> =3D=3D34679=3D=3D Using Valgrind-3.6.1 and LibVEX; rerun with -h for c= opyright info > >> =3D=3D34679=3D=3D Command: ./yttool > >> =3D=3D34679=3D=3D > >> =3D=3D34679=3D=3D > >> =3D=3D34679=3D=3D HEAP SUMMARY: > >> =3D=3D34679=3D=3D in use at exit: 20,395 bytes in 119 blocks > >> =3D=3D34679=3D=3D total heap usage: 6,719 allocs, 6,600 frees, 716,7= 87 bytes allocated > >> =3D=3D34679=3D=3D > >> =3D=3D34679=3D=3D LEAK SUMMARY: > >> =3D=3D34679=3D=3D definitely lost: 0 bytes in 0 blocks > >> =3D=3D34679=3D=3D indirectly lost: 0 bytes in 0 blocks > >> =3D=3D34679=3D=3D possibly lost: 134 bytes in 4 blocks > >> =3D=3D34679=3D=3D still reachable: 20,261 bytes in 115 blocks > >> =3D=3D34679=3D=3D suppressed: 0 bytes in 0 blocks > >> =3D=3D34679=3D=3D Rerun with --leak-check=3Dfull to see details of lea= ked memory > >> =3D=3D34679=3D=3D > >> =3D=3D34679=3D=3D For counts of detected and suppressed errors, rerun = with: -v > >> =3D=3D34679=3D=3D 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=3Dmemcheck ./yttool > >> valgrind: Startup or configuration error: > >> valgrind: Can't establish current working directory at startup > >> valgrind: Unable to start up properly. Giving up. > >=20 > > 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". > > :-) > >=20 > > 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: > >=20 > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/fs/nullfs/ > >=20 > > I'm CC'ing Kostik (kib@) as he might have some ideas. > >=20 > > 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=3D161424>; Nullfs VNTOCNP implementation has a known deficiency. Working on the item is in my TODO list. >=20 > >=20 > > 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 coole= r. :) >=20 > --=20 > VZ >=20 --4qkYhMaAfKuF3v0Q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk6RresACgkQC3+MBN1Mb4hV/QCff5dcALDi9nQMjlD083dxLM5E oJwAniNe42EWKYGHbnlRFvPo85zFEpei =xwGw -----END PGP SIGNATURE----- --4qkYhMaAfKuF3v0Q--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111009142131.GQ1511>