|
From: Johan E. <jo...@ek...> - 2004-04-24 21:09:25
|
After configure + make install 2.0.0 or 2.1.1, valgrind won't start at =
all:
2.0.0: # valgrind
valgrind.so: When searching for client's argc/argc/envp:
Cannot determine stack segment from /proc/self/maps
valgrind.so: Startup or configuration error:
couldn't find client's argc/argc/envp
valgrind.so: Unable to start up properly. Giving up.
2.1.1: # valgrind
www2:/usr/src/valgrind-2.1.1# valgrind
Executable is mapped outside of range 0x80d3000-0xb0b19000
failed to load /usr/local/lib/valgrind/stage2: Cannot allocate memory
(2.1.1 can also segfault directly w/o any error message at all)
System originally Slackware 8.0, but many upgrades over the years
# uname -a
Linux www2 2.4.25-grsec #2 SMP Mon Feb 23 17:59:20 CET 2004 i686 unknown
# gcc --version
gcc (GCC) 3.2.3
# ld --version
GNU ld version 2.14.90.0.6 20030820
glibc 2.3.2 (earlier was 2.2.5)
# ls -l /lib/ld-linux.so.2
lrwxrwxrwx 1 root root 11 Apr 23 17:31 /lib/ld-linux.so.2 -> =
ld-2.3.2.so
I guess there's some inconsistency in my system setup, but I have no =
idea what to look for.
Please help!
Best regards,
/Johan Ekenberg
|
|
From: Nicholas N. <nj...@ca...> - 2004-04-26 08:28:01
|
On Sat, 24 Apr 2004, Johan Ekenberg wrote: > After configure + make install 2.0.0 or 2.1.1, valgrind won't start at all: > > 2.0.0: # valgrind > valgrind.so: When searching for client's argc/argc/envp: > Cannot determine stack segment from /proc/self/maps > valgrind.so: Startup or configuration error: > couldn't find client's argc/argc/envp > valgrind.so: Unable to start up properly. Giving up. > > 2.1.1: # valgrind > www2:/usr/src/valgrind-2.1.1# valgrind > Executable is mapped outside of range 0x80d3000-0xb0b19000 > failed to load /usr/local/lib/valgrind/stage2: Cannot allocate memory > (2.1.1 can also segfault directly w/o any error message at all) > > System originally Slackware 8.0, but many upgrades over the years > > # uname -a > Linux www2 2.4.25-grsec #2 SMP Mon Feb 23 17:59:20 CET 2004 i686 unknown > > # gcc --version > gcc (GCC) 3.2.3 > > # ld --version > GNU ld version 2.14.90.0.6 20030820 > > glibc 2.3.2 (earlier was 2.2.5) > # ls -l /lib/ld-linux.so.2 > lrwxrwxrwx 1 root root 11 Apr 23 17:31 /lib/ld-linux.so.2 -> ld-2.3.2.so > > > I guess there's some inconsistency in my system setup, but I have no idea what to look for. > Please help! Hmm... have you tried 2.1.0? It's hard to say what the problem is, due to the "many patches". Not much help, I know; sorry. N |
|
From: Johan E. <jo...@ek...> - 2004-04-26 13:05:42
|
> -----Original Message----- > From: val...@li... > [mailto:val...@li...]On Behalf Of = Nicholas > Nethercote > Sent: Monday, April 26, 2004 10:28 AM > To: Johan Ekenberg > Cc: val...@li... > Subject: Re: [Valgrind-users] can't run valgrind at all >=20 >=20 > On Sat, 24 Apr 2004, Johan Ekenberg wrote: >=20 > > After configure + make install 2.0.0 or 2.1.1, valgrind won't=20 > start at all: > > > > 2.0.0: # valgrind > > valgrind.so: When searching for client's argc/argc/envp: > > Cannot determine stack segment from /proc/self/maps > > valgrind.so: Startup or configuration error: > > couldn't find client's argc/argc/envp > > valgrind.so: Unable to start up properly. Giving up. > > > > 2.1.1: # valgrind > > www2:/usr/src/valgrind-2.1.1# valgrind > > Executable is mapped outside of range 0x80d3000-0xb0b19000 > > failed to load /usr/local/lib/valgrind/stage2: Cannot allocate = memory > > (2.1.1 can also segfault directly w/o any error message at all) > > > > System originally Slackware 8.0, but many upgrades over the years > > > > # uname -a > > Linux www2 2.4.25-grsec #2 SMP Mon Feb 23 17:59:20 CET 2004 i686 = unknown > > > > # gcc --version > > gcc (GCC) 3.2.3 > > > > # ld --version > > GNU ld version 2.14.90.0.6 20030820 > > > > glibc 2.3.2 (earlier was 2.2.5) > > # ls -l /lib/ld-linux.so.2 > > lrwxrwxrwx 1 root root 11 Apr 23 17:31=20 > /lib/ld-linux.so.2 -> ld-2.3.2.so > > > > > > I guess there's some inconsistency in my system setup, but I=20 > have no idea what to look for. > > Please help! >=20 > Hmm... have you tried 2.1.0? It's hard to say what the problem is, = due to > the "many patches". Not much help, I know; sorry. First let me refrase a little: The only "patch" I believe has affected = valgrind is the upgrade from glibc 2.2.5 to 2.3.2. valgrind built and = worked well before that upgrade, but not after. I tried building valgrind-2.1.0 but it wouldn't even compile: vg_proxylwp.c:199: warning: unnamed struct/union that defines no = instances vg_proxylwp.c: In function `proxylwp': vg_proxylwp.c:515: structure has no member named `siginfo' vg_proxylwp.c:557: structure has no member named `syscallno' vg_proxylwp.c:602: structure has no member named `syscallno' vg_proxylwp.c:611: structure has no member named `syscallno' vg_proxylwp.c:715: structure has no member named `syscallno' vg_proxylwp.c:726: structure has no member named `syscallno' vg_proxylwp.c: In function `sys_wait_results': vg_proxylwp.c:1154: structure has no member named `syscallno' vg_proxylwp.c:1163: structure has no member named `siginfo' vg_proxylwp.c:1165: structure has no member named `siginfo' vg_proxylwp.c:1168: structure has no member named `siginfo' make[3]: *** [vg_proxylwp.o] Error 1 make[3]: Leaving directory `/usr/src/valgrind-2.1.0/coregrind' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/src/valgrind-2.1.0/coregrind' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/src/valgrind-2.1.0' make: *** [all] Error 2 I'm in DEEP NEED of valgrind on this system and sincerely ask and hope = for any help you can give! Best regards, /Johan |
|
From: Johan E. <jo...@ek...> - 2004-04-30 05:00:34
|
I suddenly realized that the kernel on the machine is patched with grsec = (www.grsecurity.net) including PaX Address Space Modification = Protection. This includes removal of addresses from = /proc/<pid>/[maps|stat] which explains valgrind crashing. After using = the chpax utility to remove this restriction from the valgrind binary = (2.1.1) or /bin/true (2.0.0) plus the program to be debugged, it works. Sorry for this, my mistake indeed. Possibly one could imagine an = extended error message from valgrind in case of problems reading = /proc/self/maps, just to help morons like me :) ("Can't read = /proc/self/maps, are you using some kind of security scheme which causes = this?") Best regards and thanks, /Johan > -----Original Message----- > From: val...@li... > [mailto:val...@li...]On Behalf Of Johan > Ekenberg > Sent: Monday, April 26, 2004 3:05 PM > To: Nicholas Nethercote > Cc: val...@li... > Subject: RE: [Valgrind-users] can't run valgrind at all >=20 >=20 > > -----Original Message----- > > From: val...@li... > > [mailto:val...@li...]On Behalf Of = Nicholas > > Nethercote > > Sent: Monday, April 26, 2004 10:28 AM > > To: Johan Ekenberg > > Cc: val...@li... > > Subject: Re: [Valgrind-users] can't run valgrind at all > >=20 > >=20 > > On Sat, 24 Apr 2004, Johan Ekenberg wrote: > >=20 > > > After configure + make install 2.0.0 or 2.1.1, valgrind won't=20 > > start at all: > > > > > > 2.0.0: # valgrind > > > valgrind.so: When searching for client's argc/argc/envp: > > > Cannot determine stack segment from /proc/self/maps > > > valgrind.so: Startup or configuration error: > > > couldn't find client's argc/argc/envp > > > valgrind.so: Unable to start up properly. Giving up. > > > > > > 2.1.1: # valgrind > > > www2:/usr/src/valgrind-2.1.1# valgrind > > > Executable is mapped outside of range 0x80d3000-0xb0b19000 > > > failed to load /usr/local/lib/valgrind/stage2: Cannot=20 > allocate memory > > > (2.1.1 can also segfault directly w/o any error message at all) > > > > > > System originally Slackware 8.0, but many upgrades over the years > > > > > > # uname -a > > > Linux www2 2.4.25-grsec #2 SMP Mon Feb 23 17:59:20 CET 2004=20 > i686 unknown > > > > > > # gcc --version > > > gcc (GCC) 3.2.3 > > > > > > # ld --version > > > GNU ld version 2.14.90.0.6 20030820 > > > > > > glibc 2.3.2 (earlier was 2.2.5) > > > # ls -l /lib/ld-linux.so.2 > > > lrwxrwxrwx 1 root root 11 Apr 23 17:31=20 > > /lib/ld-linux.so.2 -> ld-2.3.2.so > > > > > > > > > I guess there's some inconsistency in my system setup, but I=20 > > have no idea what to look for. > > > Please help! > >=20 > > Hmm... have you tried 2.1.0? It's hard to say what the problem=20 > is, due to > > the "many patches". Not much help, I know; sorry. >=20 > First let me refrase a little: The only "patch" I believe has=20 > affected valgrind is the upgrade from glibc 2.2.5 to 2.3.2.=20 > valgrind built and worked well before that upgrade, but not after. >=20 > I tried building valgrind-2.1.0 but it wouldn't even compile: >=20 > vg_proxylwp.c:199: warning: unnamed struct/union that defines no = instances > vg_proxylwp.c: In function `proxylwp': > vg_proxylwp.c:515: structure has no member named `siginfo' > vg_proxylwp.c:557: structure has no member named `syscallno' > vg_proxylwp.c:602: structure has no member named `syscallno' > vg_proxylwp.c:611: structure has no member named `syscallno' > vg_proxylwp.c:715: structure has no member named `syscallno' > vg_proxylwp.c:726: structure has no member named `syscallno' > vg_proxylwp.c: In function `sys_wait_results': > vg_proxylwp.c:1154: structure has no member named `syscallno' > vg_proxylwp.c:1163: structure has no member named `siginfo' > vg_proxylwp.c:1165: structure has no member named `siginfo' > vg_proxylwp.c:1168: structure has no member named `siginfo' > make[3]: *** [vg_proxylwp.o] Error 1 > make[3]: Leaving directory `/usr/src/valgrind-2.1.0/coregrind' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory `/usr/src/valgrind-2.1.0/coregrind' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/usr/src/valgrind-2.1.0' > make: *** [all] Error 2 >=20 > I'm in DEEP NEED of valgrind on this system and sincerely ask and=20 > hope for any help you can give! >=20 > Best regards, > /Johan >=20 >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek > For a limited time only, get FREE Ground shipping on all orders of $35 > or more. Hurry up and shop folks, this offer expires April 30th! > http://www.thinkgeek.com/freeshipping/?cpg=12297 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Nicholas N. <nj...@ca...> - 2004-04-30 10:07:04
|
On Fri, 30 Apr 2004, Johan Ekenberg wrote: > I suddenly realized that the kernel on the machine is patched with grsec > (www.grsecurity.net) including PaX Address Space Modification > Protection. This includes removal of addresses from > /proc/<pid>/[maps|stat] which explains valgrind crashing. After using > the chpax utility to remove this restriction from the valgrind binary > (2.1.1) or /bin/true (2.0.0) plus the program to be debugged, it works. > > Sorry for this, my mistake indeed. Possibly one could imagine an > extended error message from valgrind in case of problems reading > /proc/self/maps, just to help morons like me :) ("Can't read > /proc/self/maps, are you using some kind of security scheme which causes > this?") Good to hear you solved the problem. Others have had problems with PaX and Valgrind before, but it a different way. They complained that Valgrind aborted when reading the /proc/self/maps because the format was different. (PaX introduces permissions like "R+X-", not just like "r-x-".) See bug 77968 (http://bugs.kde.org/show_bug.cgi?id=77968). So it's surprising that you get this different problem -- sounds like your version of PaX doesn't have these different permission strings, which is good. But the "removal of addresses" sounds very bad for Valgrind -- do you have more information about what happens here, and why PaX does it? If /proc/self/maps doesn't truly reflect the memory mappings, Valgrind will definitely be in trouble. Thanks. N |
|
From: Johan E. <jo...@ek...> - 2004-04-30 12:03:10
|
> > I suddenly realized that the kernel on the machine is patched with = grsec > > (www.grsecurity.net) including PaX Address Space Modification > > Protection. This includes removal of addresses from > > /proc/<pid>/[maps|stat] which explains valgrind crashing. After = using > > the chpax utility to remove this restriction from the valgrind = binary > > (2.1.1) or /bin/true (2.0.0) plus the program to be debugged, it = works. > > > > Sorry for this, my mistake indeed. Possibly one could imagine an > > extended error message from valgrind in case of problems reading > > /proc/self/maps, just to help morons like me :) ("Can't read > > /proc/self/maps, are you using some kind of security scheme which = causes > > this?") >=20 > Good to hear you solved the problem. Others have had problems with = PaX > and Valgrind before, but it a different way. They complained that > Valgrind aborted when reading the /proc/self/maps because the format = was > different. (PaX introduces permissions like "R+X-", not just like > "r-x-".) See bug 77968 (http://bugs.kde.org/show_bug.cgi?id=3D77968). >=20 > So it's surprising that you get this different problem -- sounds like = your > version of PaX doesn't have these different permission strings, which = is > good. But the "removal of addresses" sounds very bad for Valgrind -- = do > you have more information about what happens here, and why PaX does = it? > If /proc/self/maps doesn't truly reflect the memory mappings, Valgrind > will definitely be in trouble. From the grsec kernel-config-help: =3D=3D=3D=3D CONFIG_GRKERNSEC_PROC_MEMMAP: = If you say Y here, the /proc/<pid>/maps and /proc/<pid>/stat files = will give no information about the addresses of its mappings if PaX features that rely on random addresses are enabled on the task. If you use PaX it is greatly recommended that you say Y here as it closes up a hole that makes the full ASLR useless for suid binaries. =3D=3D=3D=3D Look at this example: =3D=3D=3D=3D # cat /proc/self/maps 00000000-00000000 r-xp 00000000 30:00 19 /bin/cat 00000000-00000000 rw-p 00001000 30:00 19 /bin/cat 00000000-00000000 rwxp 00000000 00:00 0 00000000-00000000 r-xp 00000000 30:00 60854 /lib/ld-2.3.2.so 00000000-00000000 rw-p 00014000 30:00 60854 /lib/ld-2.3.2.so 00000000-00000000 r-xp 00000000 30:00 60531 /lib/libc-2.3.2.so 00000000-00000000 rw-p 0012f000 30:00 60531 /lib/libc-2.3.2.so 00000000-00000000 rw-p 00000000 00:00 0 00000000-00000000 r--p 00000000 30:00 85818108 = /usr/lib/locale/locale-archive 00000000-00000000 rwxp fffff000 00:00 0 # chpax -r /bin/cat # cat /proc/self/maps 08048000-0804a000 r-xp 00000000 30:00 19 /bin/cat 0804a000-0804b000 rw-p 00001000 30:00 19 /bin/cat 0804b000-0804d000 rwxp 00000000 00:00 0 40000000-40015000 r-xp 00000000 30:00 60854 /lib/ld-2.3.2.so 40015000-40016000 rw-p 00014000 30:00 60854 /lib/ld-2.3.2.so 4001d000-4014c000 r-xp 00000000 30:00 60531 /lib/libc-2.3.2.so 4014c000-40151000 rw-p 0012f000 30:00 60531 /lib/libc-2.3.2.so 40151000-40154000 rw-p 00000000 00:00 0 40154000-40354000 r--p 00000000 30:00 85818108 = /usr/lib/locale/locale-archive bfffe000-c0000000 rwxp fffff000 00:00 0 =3D=3D=3D=3D So - the solution to run valgrind in this environment is to "chpax -r" = the valgrind executable and the program to be run under valgrinds = control. In version 2.0.0 valgrind is a shellscript which uses = /bin/true, so /bin/true also has to be "chpax -r". /Johan |
|
From: Nicholas N. <nj...@ca...> - 2004-04-30 12:06:58
|
On Fri, 30 Apr 2004, Johan Ekenberg wrote: > ==== > CONFIG_GRKERNSEC_PROC_MEMMAP: > If you say Y here, the /proc/<pid>/maps and /proc/<pid>/stat files will > give no information about the addresses of its mappings if > PaX features that rely on random addresses are enabled on the task. > If you use PaX it is greatly recommended that you say Y here as it > closes up a hole that makes the full ASLR useless for suid binaries. > ==== > > Look at this example: > > ==== > # cat /proc/self/maps > 00000000-00000000 r-xp 00000000 30:00 19 /bin/cat > 00000000-00000000 rw-p 00001000 30:00 19 /bin/cat > 00000000-00000000 rwxp 00000000 00:00 0 > 00000000-00000000 r-xp 00000000 30:00 60854 /lib/ld-2.3.2.so > 00000000-00000000 rw-p 00014000 30:00 60854 /lib/ld-2.3.2.so > 00000000-00000000 r-xp 00000000 30:00 60531 /lib/libc-2.3.2.so > 00000000-00000000 rw-p 0012f000 30:00 60531 /lib/libc-2.3.2.so > 00000000-00000000 rw-p 00000000 00:00 0 > 00000000-00000000 r--p 00000000 30:00 85818108 /usr/lib/locale/locale-archive > 00000000-00000000 rwxp fffff000 00:00 0 Good grief. I wonder how many other programs this breaks? N |
|
From: Johan E. <jo...@ek...> - 2004-04-30 12:42:45
|
> > CONFIG_GRKERNSEC_PROC_MEMMAP: > > If you say Y here, the /proc/<pid>/maps and /proc/<pid>/stat=20 > files will > > give no information about the addresses of its mappings if > > PaX features that rely on random addresses are enabled on the = task. > > If you use PaX it is greatly recommended that you say Y here as it > > closes up a hole that makes the full ASLR useless for suid = binaries. > > =3D=3D=3D=3D > > > > Look at this example: > > > > =3D=3D=3D=3D > > # cat /proc/self/maps > > 00000000-00000000 r-xp 00000000 30:00 19 /bin/cat > > 00000000-00000000 rw-p 00001000 30:00 19 /bin/cat > > 00000000-00000000 rwxp 00000000 00:00 0 > > 00000000-00000000 r-xp 00000000 30:00 60854 /lib/ld-2.3.2.so > > 00000000-00000000 rw-p 00014000 30:00 60854 /lib/ld-2.3.2.so > > 00000000-00000000 r-xp 00000000 30:00 60531 = /lib/libc-2.3.2.so > > 00000000-00000000 rw-p 0012f000 30:00 60531 = /lib/libc-2.3.2.so > > 00000000-00000000 rw-p 00000000 00:00 0 > > 00000000-00000000 r--p 00000000 30:00 85818108 =20 > /usr/lib/locale/locale-archive > > 00000000-00000000 rwxp fffff000 00:00 0 >=20 > Good grief. I wonder how many other programs this breaks? We've been running with this setup for a long time on +20 busy = www-servers with a total of about 18000 users, without any problems = except valgrind. So for a traditional server setup it doesn't seem to = break anything. Can't say anything about X-applications, desktop stuff = etc. /Johan |