From owner-freebsd-stable@FreeBSD.ORG Sun Oct 9 14:19:15 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54F82106566B for ; Sun, 9 Oct 2011 14:19:15 +0000 (UTC) (envelope-from v.haisman@sh.cvut.cz) Received: from service1.sh.cvut.cz (service1.sh.cvut.cz [IPv6:2001:718:2::214]) by mx1.freebsd.org (Postfix) with ESMTP id 52F438FC08 for ; Sun, 9 Oct 2011 14:19:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by service1.sh.cvut.cz (Postfix) with ESMTP id 7832A124B4A; Sun, 9 Oct 2011 16:19:13 +0200 (CEST) X-Spam-Score: -100.281 X-Spam-Level: X-Spam-Status: No, score=-100.281 tagged_above=-255 required=5 tests=[ALL_TRUSTED=-1.44, AWL=0.733, CRM114_HAM_00=, RATWARE_GECKO_BUILD=1.426, SMTPAUTH_SHDOMAIN=-100] Received: from service1.sh.cvut.cz ([127.0.0.1]) by localhost (service1.sh.cvut.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvLvVU9VTgLQ; Sun, 9 Oct 2011 16:19:05 +0200 (CEST) Received: from [10.0.0.1] (242.91.broadband5.iol.cz [88.100.91.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: v.haisman@sh.cvut.cz) by service1.sh.cvut.cz (Postfix) with ESMTP id 61A31124AD1; Sun, 9 Oct 2011 16:19:05 +0200 (CEST) Message-ID: <4E91AD48.5070906@sh.cvut.cz> Date: Sun, 09 Oct 2011 16:18:48 +0200 From: =?UTF-8?B?VsOhY2xhdiBaZW1hbg==?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org 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> In-Reply-To: <20111009141117.GA47243@icarus.home.lan> X-Enigmail-Version: 1.3.2 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigB7CD7820DF6E895741743554" Subject: Re: valgrind on FreeBSD? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2011 14:19:15 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB7CD7820DF6E895741743554 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 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 o= r >>> 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 underlyin= g > 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: = >=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 jus= t liked that it never has shown /usr there and also because it seemed coole= r. :) --=20 VZ --------------enigB7CD7820DF6E895741743554 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk6RrVgACgkQbJlIwZz1OodZdgD9GJHjOqFl8UDa+ZBXhd8JKezR MPxoT6dmvwdQbtZevXcBAMNFay5VaLbFDYi9ncetC+hdBleS+s0gjysjDo1hm8cH =8PFa -----END PGP SIGNATURE----- --------------enigB7CD7820DF6E895741743554--