Menu
▾
▴
valgrind-users
|
From: Mikhail B. <mik...@de...> - 2014-11-27 20:23:21
|
Hello I built valgrind 3.10.1 for arm platform (on amd64 host system) and got a problem. Memcheck fails finding problems even in /bin/true # valgrind /bin/true ==1654== Memcheck, a memory error detector ==1654== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==1654== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info ==1654== Command: /bin/true ==1654== ==1654== Invalid read of size 4 ==1654== at 0x40071B0: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.32.1.so) ==1654== Address 0xbdd749d4 is on thread 1's stack ==1654== 20 bytes below stack pointer ==1654== ==1654== Invalid read of size 4 ==1654== at 0x489B248: __uClibc_main (in /lib/libuClibc-0.9.32.1.so) ==1654== Address 0xbdd74b44 is on thread 1's stack ==1654== 20 bytes below stack pointer ==1654== ==1654== Invalid read of size 4 ==1654== at 0x489B02C: __uClibc_fini (in /lib/libuClibc-0.9.32.1.so) ==1654== Address 0xbdd74aec is on thread 1's stack ==1654== 20 bytes below stack pointer ==1654== ==1654== Invalid read of size 4 ==1654== at 0x4002324: ??? (in /lib/ld-uClibc-0.9.32.1.so) ==1654== Address 0xbdd74ab4 is on thread 1's stack ==1654== 20 bytes below stack pointer ==1654== /bin/true: can't resolve symbol '__libc_freeres' ==1654== ==1654== HEAP SUMMARY: ==1654== in use at exit: 0 bytes in 0 blocks ==1654== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==1654== ==1654== All heap blocks were freed -- no leaks are possible ==1654== ==1654== For counts of detected and suppressed errors, rerun with: -v ==1654== ERROR SUMMARY: 48 errors from 4 contexts (suppressed: 0 from 0) I also have # valgrind -v -v -v -d -d -d --trace-redir=yes /bin/true log but it's really big to attach it here. And i really can't understand where is the problem because I tried to build trunk valgring (which fails with the same errors), tried 3.10.0 with patches from buildroot with the same result. And now I don't know where to dig. |
|
From: Philippe W. <phi...@sk...> - 2014-11-27 20:57:28
|
On Thu, 2014-11-27 at 23:06 +0300, Mikhail Baikov wrote: > ==1654== Invalid read of size 4 > ==1654== at 0x489B248: __uClibc_main (in /lib/libuClibc-0.9.32.1.so) > ==1654== Address 0xbdd74b44 is on thread 1's stack > ==1654== 20 bytes below stack pointer > ==1654== > I also have > # valgrind -v -v -v -d -d -d --trace-redir=yes /bin/true > log but it's really big to attach it here. > > And i really can't understand where is the problem because I tried to > build trunk valgring (which fails with the same errors), tried 3.10.0 > with patches from buildroot with the same result. > > And now I don't know where to dig. A possible cause of the above problem is that valgrind does not recognise the name of the uClibc dynamic loader. There is some code that handles specially the dynamic loader. See coregrind/m_redir.c line 1363 for the expected names on arm or some similar names in include/pub_tool_redir.h It might also just be "normal" errors, that are suppressed by the standard valgrind suppression files, but that in your case are not matching due to the uClibc use ? See e.g. default.supp (generated from various *.supp files). I see no uclibc specific files there, which makes me believe valgrind is not (yet) fine tuned to be used with uclibc. For what concerns the error message /bin/true: can't resolve symbol '__libc_freeres' again that is probably caused by uClib, which I guess does not provide __libc_freeres To avoid this msg, you can use --run-libc-freeres=no Note however that I see in coregrind/vg_preloaded.c (line 59) that the call should not be done when valgrind is "compiled" for UCLIBC. So, might be good to verify how e.g. vg_preloaded.c was compiled. Philippe |
|
From: Philippe W. <phi...@sk...> - 2014-12-03 21:44:00
|
On Wed, 2014-12-03 at 19:51 +0300, Mikhail Baikov wrote: > > The main problem for me is not in basic applications. The problem is > that the application that I want to test works fine without valgrind but > segfaults when I try to run it in valgrind. > Then I might have missed something in the mail exchanges. Your initial mail said that the bug is valgrind fails to find problems even in simple applications. The example shown was with /bin/true. This was reporting 'invalid read errors' originating from ulibc loader. This I guess can be fixed by having a ulibc.supp file. So, what is the segfault in a bigger application ? Philippe |
|
From: Philippe W. <phi...@sk...> - 2014-12-05 18:26:38
|
On Thu, 2014-12-04 at 16:16 +0300, Mikhail Baikov wrote:
> And the crash... I'm sorry it's not a segfault. It's a crash.
> One of the strange things is that inspite of --run-libc-freeres set no
> in the log appears
> /bin/sh: symbol '__libc_freeres': can't resolve symbol and the rest...
This is I suppose because valgrind has not been properly compiled
for ulibc.
If you look in coregrind/vg_preloaded.c, you will see that if symbol
__UCLIBC__ is defined, then no calls to __libc_freeres();
will be generated.
So, that looks a first problem to solve : I guess you should
ensure that __UCLIBC__ is defined when you compile on the host,
and ensure to compile with the relevant uclibc headers files at
the host side.
>From what I see in the trace below, the problem happens
with /bin/sh (/bin/bash).
So, I guess none of your own executables are even started.
After first fixing the above compilation problem, you might
maybe understand better what is happening by having shell debugging
(e.g. do valgrind /bin/sh -x <your script>)
Alternatively, to simplify seeing what happens, do run valgrind
on a trivial program that does a malloc/free (hoping
this reproduces the problem you see)
and give the full trace e.g. with
-v -v -v -d -d -d --trace-malloc=yes --trace-syscalls=yes
--trace-redir=yes --trace-signals=yes
Otherwise, try the same trace with the big program, hoping
this is not GBs of traces.
Philippe
> I have no idea what exactly to show
>
> ==2633== Adding active redirection:
> --2633-- new: 0x048965d0 (valloc ) R-> (1012.0)
> 0x0481ea98 valloc
> --2633:2:transtab discard_translations(0x4896734, 1) req by
> redir_new_DebugInfo(from_addr)
> --2633:2:transtab FAST, ec = 44
> --2633:2:transtab discard_translations(0x481ea00, 1) req by
> redir_new_DebugInfo(to_addr)
> --2633:2:transtab FAST, ec = 61
> ==2633== Adding active redirection:
> --2633-- new: 0x04896734 (posix_memalign ) R-> (1016.0)
> 0x0481ea00 posix_memalign
>
> /bin/sh: symbol '__libc_freeres': can't resolve symbol
> --2633:1:syswrap- thread_wrapper(tid=1): exit, schedreturncode
> VgSrc_ExitThread
> --2633:1:syswrap- run_a_thread_NORETURN(tid=1): post-thread_wrapper
> --2633:1:syswrap- run_a_thread_NORETURN(tid=1): last one standing
> --2633:1:main entering VG_(shutdown_actions_NORETURN)
> --2633:1:aspacem <<< SHOW_SEGMENTS: Memory layout at client shutdown
> (57 segments, 9 segnames)
> --2633:1:aspacem ( 0)
> /bin/mbaikov/valgrind_arm/lib/valgrind/memcheck-arm-linux
> --2633:1:aspacem ( 1) /bin/bash
> --2633:1:aspacem ( 2) /lib/ld-uClibc-0.9.32.1.so
> --2633:1:aspacem ( 3) /tmp/vgdb-pipe-shared-mem-vgdb-2633-by-root-on-???
> --2633:1:aspacem ( 4)
> /bin/mbaikov/valgrind_arm/lib/valgrind/vgpreload_core-arm-linux.so
> --2633:1:aspacem ( 5)
> /bin/mbaikov/valgrind_arm/lib/valgrind/vgpreload_memcheck-arm-linux.so
> --2633:1:aspacem ( 6) /lib/libdl-0.9.32.1.so
> --2633:1:aspacem ( 7) /lib/libgcc_s.so.1
> --2633:1:aspacem ( 8) /lib/libuClibc-0.9.32.1.so
> --2633:1:aspacem 0: RSVN 0000000000-0000007fff 32768 ----- SmFixed
> --2633:1:aspacem 1: file 0000008000-00000a0fff 626688 r-x-- d=0x00c
> i=6174178 o=0 (1)
> --2633:1:aspacem 2: RSVN 00000a1000-00000a7fff 28672 ----- SmFixed
> --2633:1:aspacem 3: file 00000a8000-00000acfff 20480 rw--- d=0x00c
> i=6174178 o=622592 (1)
> --2633:1:aspacem 4: anon 00000ad000-00000b1fff 20480 rw---
> --2633:1:aspacem 5: RSVN 00000b2000-0003ffffff 63m ----- SmFixed
> --2633:1:aspacem 6: file 0004000000-0004008fff 36864 r-xT- d=0x00c
> i=6160505 o=0 (2)
> --2633:1:aspacem 7: anon 0004009000-000400afff 8192 rw---
> --2633:1:aspacem 8: 000400b000-000400ffff 20480
> --2633:1:aspacem 9: file 0004010000-0004011fff 8192 rw--- d=0x00c
> i=6160505 o=32768 (2)
> --2633:1:aspacem 10: anon 0004012000-0004012fff 4096 rwx--
> --2633:1:aspacem 11: RSVN 0004013000-0004811fff 8384512 ----- SmLower
> --2633:1:aspacem 12: file 0004812000-0004812fff 4096 r-x-- d=0x00c
> i=6948052 o=0 (4)
> --2633:1:aspacem 13: anon 0004813000-0004819fff 28672 -----
> --2633:1:aspacem 14: file 000481a000-000481afff 4096 rw--- d=0x00c
> i=6948052 o=0 (4)
> --2633:1:aspacem 15: file 000481b000-0004827fff 53248 r-x-- d=0x00c
> i=6948058 o=0 (5)
> --2633:1:aspacem 16: anon 0004828000-000482efff 28672 -----
> --2633:1:aspacem 17: file 000482f000-000482ffff 4096 rw--- d=0x00c
> i=6948058 o=49152 (5)
> --2633:1:aspacem 18: file 0004830000-0004832fff 12288 r-x-- d=0x00c
> i=6160501 o=0 (6)
> --2633:1:aspacem 19: anon 0004833000-0004839fff 28672 -----
> --2633:1:aspacem 20: file 000483a000-000483bfff 8192 rw--- d=0x00c
> i=6160501 o=8192 (6)
> --2633:1:aspacem 21: file 000483c000-0004845fff 40960 r-x-- d=0x00c
> i=6160503 o=0 (7)
> --2633:1:aspacem 22: anon 0004846000-000484cfff 28672 -----
> --2633:1:aspacem 23: file 000484d000-000484dfff 4096 rw--- d=0x00c
> i=6160503 o=36864 (7)
> --2633:1:aspacem 24: file 000484e000-00048d5fff 557056 r-x-- d=0x00c
> i=6160509 o=0 (8)
> --2633:1:aspacem 25: anon 00048d6000-00048dcfff 28672 -----
> --2633:1:aspacem 26: file 00048dd000-00048defff 8192 rw--- d=0x00c
> i=6160509 o=552960 (8)
> --2633:1:aspacem 27: anon 00048df000-00048e3fff 20480 rw---
> --2633:1:aspacem 28: 00048e4000-0037ffffff 823m
> --2633:1:aspacem 29: FILE 0038000000-0038057fff 360448 r-x-- d=0x00c
> i=6947992 o=0 (0)
> --2633:1:aspacem 30: file 0038058000-0038058fff 4096 r-x-- d=0x00c
> i=6947992 o=360448 (0)
> --2633:1:aspacem 31: FILE 0038059000-00383cffff 3633152 r-x-- d=0x00c
> i=6947992 o=364544 (0)
> --2633:1:aspacem 32: FILE 00383d0000-00383d4fff 20480 rw--- d=0x00c
> i=6947992 o=3997696 (0)
> --2633:1:aspacem 33: ANON 00383d5000-0039500fff 17m rw---
> --2633:1:aspacem 34: 0039501000-006159dfff 640m
> --2633:1:aspacem 35: RSVN 006159e000-006159efff 4096 ----- SmFixed
> --2633:1:aspacem 36: ANON 006159f000-0062139fff 11m rwx--
> --2633:1:aspacem 37: 006213a000-006213bfff 8192
> --2633:1:aspacem 38: FILE 006213c000-006213cfff 4096 rw--- d=0x00e
> i=2198 o=0 (3)
> --2633:1:aspacem 39: ANON 006213d000-0062164fff 163840 rwx--
> --2633:1:aspacem 40: 0062165000-0062219fff 741376
> --2633:1:aspacem 41: ANON 006221a000-0062319fff 1048576 rwx--
> --2633:1:aspacem 42: ANON 006231a000-006231bfff 8192 -----
> --2633:1:aspacem 43: ANON 006231c000-006241bfff 1048576 rwx--
> --2633:1:aspacem 44: ANON 006241c000-006241dfff 8192 -----
> --2633:1:aspacem 45: 006241e000-006250efff 987136
> --2633:1:aspacem 46: ANON 006250f000-006274dfff 2355200 rwx--
> --2633:1:aspacem 47: 006274e000-00628f7fff 1744896
> --2633:1:aspacem 48: ANON 00628f8000-0064fa6fff 38m rwx--
> --2633:1:aspacem 49: 0064fa7000-00bd33cfff 1411m
> --2633:1:aspacem 50: RSVN 00bd33d000-00bdb3afff 8380416 ----- SmUpper
> --2633:1:aspacem 51: anon 00bdb3b000-00bdb3cfff 8192 rw---
> --2633:1:aspacem 52: 00bdb3d000-00beb1bfff 15m
> --2633:1:aspacem 53: ANON 00beb1c000-00beb3cfff 135168 rw---
> --2633:1:aspacem 54: RSVN 00beb3d000-00fffeffff 1044m ----- SmFixed
> --2633:1:aspacem 55: anon 00ffff0000-00ffff0fff 4096 r-x--
> --2633:1:aspacem 56: RSVN 00ffff1000-00ffffffff 61440 ----- SmFixed
> --2633:1:aspacem >>>
> ==2633==
> ==2633== HEAP SUMMARY:
> ==2633== in use at exit: 0 bytes in 0 blocks
> ==2633== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
> ==2633==
> ==2633== All heap blocks were freed -- no leaks are possible
> ==2633==
> ==2633== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
> ==2633== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
> --2633:1:gdbsrv VG core calling VG_(gdbserver_exit) tid 1 will exit
> --2633:1:gdbsrv not connected
> --2633:1:gdbsrv remote_finish (reason orderly_finish) 1030 -1
> --2633:1:gdbsrv 2633 (creator 2633) maybe unlinking
> /tmp/vgdb-pipe-from-vgdb-to-2633-by-root-on-???
> /tmp/vgdb-pipe-to-vgdb-from-2633-by-root-on-???
> /tmp/vgdb-pipe-shared-mem-vgdb-2633-by-root-on-???
> --2633:1:core_os VG_(terminate_NORETURN)(tid=1)
> Supervisor has crashed at Thu Jan 1 08:10:47 EST 1970, exit code 255
>
>
|
|
From: Mikhail B. <mik...@de...> - 2014-12-03 16:51:35
|
> On Thu, 2014-11-27 at 23:06 +0300, Mikhail Baikov wrote: > >> ==1654== Invalid read of size 4 >> ==1654== at 0x489B248: __uClibc_main (in /lib/libuClibc-0.9.32.1.so) >> ==1654== Address 0xbdd74b44 is on thread 1's stack >> ==1654== 20 bytes below stack pointer >> ==1654== >> I also have >> # valgrind -v -v -v -d -d -d --trace-redir=yes /bin/true >> log but it's really big to attach it here. >> >> And i really can't understand where is the problem because I tried to >> build trunk valgring (which fails with the same errors), tried 3.10.0 >> with patches from buildroot with the same result. >> >> And now I don't know where to dig. > A possible cause of the above problem is that valgrind does > not recognise the name of the uClibc dynamic loader. > There is some code that handles specially the dynamic loader. > See coregrind/m_redir.c line 1363 for the expected names on arm > or some similar names in include/pub_tool_redir.h In include/pub_tool_redir.h there is a # define VG_Z_LIBC_SONAME libcZdsoZa // libc.so* that corresponds with what I have in my /lib directory ls -la /lib/libc.so.0 lrwxrwxrwx 1 root root 21 Nov 18 2014 /lib/libc.so.0 -> libuClibc-0.9.32.1.so # readelf -a /lib/libuClibc-0.9.32.1.so | grep soname 0x0000000e (SONAME) Library soname: [libc.so.0] In coregrind/m_redir.c there are two ld-linux.so.3 and ld-linux-armhf.so.3 loader names. If I add ld-uClibc.so.0 loader, rebuild valgrind and try to run any binary i get this kind of error valgrind: Fatal error at startup: a function redirection valgrind: which is mandatory for this platform-tool combination valgrind: cannot be set up. Details of the redirection are: valgrind: valgrind: A must-be-redirected function valgrind: whose name matches the pattern: strcmp valgrind: in an object with soname matching: ld-uClibc.so.0 valgrind: was not found whilst processing valgrind: symbols from the object with soname: ld-uClibc.so.0 > It might also just be "normal" errors, that are suppressed > by the standard valgrind suppression files, but that in your > case are not matching due to the uClibc use ? > See e.g. default.supp (generated from various *.supp files). > I see no uclibc specific files there, which makes me believe > valgrind is not (yet) fine tuned to be used with uclibc. > > For what concerns the error message > /bin/true: can't resolve symbol '__libc_freeres' > again that is probably caused by uClib, which I guess does not > provide __libc_freeres > To avoid this msg, you can use --run-libc-freeres=no I've taken uclibc.supp from buildroot and added suppression option with it but it hasn't helped. > Note however that I see in coregrind/vg_preloaded.c (line 59) > that the call should not be done when valgrind is "compiled" > for UCLIBC. > So, might be good to verify how e.g. vg_preloaded.c was > compiled. gcc -v of the toolchain i've been given is ./arm-linux-uclibcgnueabi-gcc -v Using built-in specs. COLLECT_GCC=./arm-linux-uclibcgnueabi-gcc COLLECT_LTO_WRAPPER=/home/mikhail/zodiac/toolchain/humax-fxpp/opt/toolchains/stbgcc-4.5.4-2.7_uclibc_ssp/bin/../libexec/gcc/arm-linux-uclibcgnueabi/4.5.4/lto-wrapper Target: arm-linux-uclibcgnueabi Configured with: ../gcc-4.5.4/configure --target=arm-linux-uclibcgnueabi --enable-multilib --prefix=/usr/src/redhat/BUILD/build-toolchain//opt/toolchains/stbgcc-4.5.4-2.7_uclibc_ssp --with-local-prefix=/usr/src/redhat/BUILD/build-toolchain//opt/toolchains/stbgcc-4.5.4-2.7_uclibc_ssp/arm-linux-uclibcgnueabi/sys-root --with-sysroot=/usr/src/redhat/BUILD/build-toolchain//opt/toolchains/stbgcc-4.5.4-2.7_uclibc_ssp/arm-linux-uclibcgnueabi/sys-root --enable-threads=posix --enable-long-long --enable-c99 --enable-__cxa_atexit --with-gmp=/usr/src/redhat/BUILD/prereq --with-mpfr=/usr/src/redhat/BUILD/prereq --with-mpc=/usr/src/redhat/BUILD/prereq --with-libelf=/usr/src/redhat/BUILD/prereq --disable-nls --enable-symvers=gnu --enable-languages=c,c++ --enable-target-optspace --with-pkgversion='Broadcom stbgcc-4.5.4-2.7_uclibc_ssp' --with-host-libstdcxx='-Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-float=soft Thread model: posix gcc version 4.5.4 (Broadcom stbgcc-4.5.4-2.7_uclibc_ssp) The single line where I see something about vg_preloaded.c is /home/mikhail/zodiac/toolchain/humax-fxpp/opt/toolchains/stbgcc-4.5.4-2.7_uclibc_ssp/bin/../libexec/gcc/arm-linux-uclibcgnueabi/4.5.4/cc1 -quiet -v -I. -I.. -I.. -I../include -I../VEX/pub -I../VEX/pub -I../coregrind -iprefix /home/mikhail/zodiac/toolchain/humax-fxpp/opt/toolchains/stbgcc-4.5.4-2.7_uclibc_ssp/bin/../lib/gcc/arm-linux-uclibcgnueabi/4.5.4/ -isysroot /home/mikhail/zodiac/toolchain/humax-fxpp/opt/toolchains/stbgcc-4.5.4-2.7_uclibc_ssp/bin/../arm-linux-uclibcgnueabi/sys-root -MD vgpreload_core_arm_linux_so-vg_preloaded.d -MF .deps/vgpreload_core_arm_linux_so-vg_preloaded.Tpo -MP -MT vgpreload_core_arm_linux_so-vg_preloaded.o -DHAVE_CONFIG_H -DVGA_arm=1 -DVGO_linux=1 -DVGP_arm_linux=1 -DVGPV_arm_linux_vanilla=1 -DVG_LIBDIR="/bin/mbaikov/valgrind_arm/lib/valgrind" -DVG_PLATFORM="arm-linux" vg_preloaded.c -quiet -dumpbase vg_preloaded.c -marm -mcpu=cortex-a8 -marm -mabi=aapcs-linux -msoft-float -muclibc -auxbase-strip vgpreload_core_arm_linux_so-vg_preloaded.o -g -g -O2 -O -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-format-zero-length -Wno-long-long -Wall -Wno-endif-labels -Wno-multichar -Wno-switch -Wno-unknown-pragmas -Wsystem-headers -Wno-unused-parameter -Wno-missing-field-initializers -version -fpic -fno-builtin -fPIC -fmerge-constants -funswitch-loops -fno-jump-tables -fno-strict-aliasing -fno-omit-frame-pointer -fno-stack-protector -o /tmp/cchpJUN3.s and I can't get whether it is compiled for uClibc or not. > Philippe > > The main problem for me is not in basic applications. The problem is that the application that I want to test works fine without valgrind but segfaults when I try to run it in valgrind. |
|
From: Mikhail B. <mik...@de...> - 2014-12-04 13:17:03
|
On 12/04/2014 12:44 AM, Philippe Waroquiers wrote:
> Then I might have missed something in the mail exchanges.
>
> Your initial mail said that the bug is valgrind fails to find
> problems even in simple applications.
> The example shown was with /bin/true. This was reporting 'invalid read
> errors' originating from ulibc loader.
> This I guess can be fixed by having a ulibc.supp file.
>
> So, what is the segfault in a bigger application ?
>
> Philippe
>
>
The bigger application starts from valgrind with verbose debugging.
==2633== Command: ./nexus ./supervisor ./powerup-launcher
==2633==
--2633-- Valgrind options:
--2633-- -v
--2633-- -v
--2633-- -v
--2633-- -d
--2633-- -d
--2633-- -d
--2633-- --run-libc-freeres=no
--2633-- --suppressions=/bin/mbaikov/uclibc.supp
--2633-- --trace-children=yes
--2633-- --workaround-gcc296-bugs=yes
And the crash... I'm sorry it's not a segfault. It's a crash.
One of the strange things is that inspite of --run-libc-freeres set no
in the log appears
/bin/sh: symbol '__libc_freeres': can't resolve symbol and the rest... I
have no idea what exactly to show
==2633== Adding active redirection:
--2633-- new: 0x048965d0 (valloc ) R-> (1012.0)
0x0481ea98 valloc
--2633:2:transtab discard_translations(0x4896734, 1) req by
redir_new_DebugInfo(from_addr)
--2633:2:transtab FAST, ec = 44
--2633:2:transtab discard_translations(0x481ea00, 1) req by
redir_new_DebugInfo(to_addr)
--2633:2:transtab FAST, ec = 61
==2633== Adding active redirection:
--2633-- new: 0x04896734 (posix_memalign ) R-> (1016.0)
0x0481ea00 posix_memalign
/bin/sh: symbol '__libc_freeres': can't resolve symbol
--2633:1:syswrap- thread_wrapper(tid=1): exit, schedreturncode
VgSrc_ExitThread
--2633:1:syswrap- run_a_thread_NORETURN(tid=1): post-thread_wrapper
--2633:1:syswrap- run_a_thread_NORETURN(tid=1): last one standing
--2633:1:main entering VG_(shutdown_actions_NORETURN)
--2633:1:aspacem <<< SHOW_SEGMENTS: Memory layout at client shutdown
(57 segments, 9 segnames)
--2633:1:aspacem ( 0)
/bin/mbaikov/valgrind_arm/lib/valgrind/memcheck-arm-linux
--2633:1:aspacem ( 1) /bin/bash
--2633:1:aspacem ( 2) /lib/ld-uClibc-0.9.32.1.so
--2633:1:aspacem ( 3) /tmp/vgdb-pipe-shared-mem-vgdb-2633-by-root-on-???
--2633:1:aspacem ( 4)
/bin/mbaikov/valgrind_arm/lib/valgrind/vgpreload_core-arm-linux.so
--2633:1:aspacem ( 5)
/bin/mbaikov/valgrind_arm/lib/valgrind/vgpreload_memcheck-arm-linux.so
--2633:1:aspacem ( 6) /lib/libdl-0.9.32.1.so
--2633:1:aspacem ( 7) /lib/libgcc_s.so.1
--2633:1:aspacem ( 8) /lib/libuClibc-0.9.32.1.so
--2633:1:aspacem 0: RSVN 0000000000-0000007fff 32768 ----- SmFixed
--2633:1:aspacem 1: file 0000008000-00000a0fff 626688 r-x-- d=0x00c
i=6174178 o=0 (1)
--2633:1:aspacem 2: RSVN 00000a1000-00000a7fff 28672 ----- SmFixed
--2633:1:aspacem 3: file 00000a8000-00000acfff 20480 rw--- d=0x00c
i=6174178 o=622592 (1)
--2633:1:aspacem 4: anon 00000ad000-00000b1fff 20480 rw---
--2633:1:aspacem 5: RSVN 00000b2000-0003ffffff 63m ----- SmFixed
--2633:1:aspacem 6: file 0004000000-0004008fff 36864 r-xT- d=0x00c
i=6160505 o=0 (2)
--2633:1:aspacem 7: anon 0004009000-000400afff 8192 rw---
--2633:1:aspacem 8: 000400b000-000400ffff 20480
--2633:1:aspacem 9: file 0004010000-0004011fff 8192 rw--- d=0x00c
i=6160505 o=32768 (2)
--2633:1:aspacem 10: anon 0004012000-0004012fff 4096 rwx--
--2633:1:aspacem 11: RSVN 0004013000-0004811fff 8384512 ----- SmLower
--2633:1:aspacem 12: file 0004812000-0004812fff 4096 r-x-- d=0x00c
i=6948052 o=0 (4)
--2633:1:aspacem 13: anon 0004813000-0004819fff 28672 -----
--2633:1:aspacem 14: file 000481a000-000481afff 4096 rw--- d=0x00c
i=6948052 o=0 (4)
--2633:1:aspacem 15: file 000481b000-0004827fff 53248 r-x-- d=0x00c
i=6948058 o=0 (5)
--2633:1:aspacem 16: anon 0004828000-000482efff 28672 -----
--2633:1:aspacem 17: file 000482f000-000482ffff 4096 rw--- d=0x00c
i=6948058 o=49152 (5)
--2633:1:aspacem 18: file 0004830000-0004832fff 12288 r-x-- d=0x00c
i=6160501 o=0 (6)
--2633:1:aspacem 19: anon 0004833000-0004839fff 28672 -----
--2633:1:aspacem 20: file 000483a000-000483bfff 8192 rw--- d=0x00c
i=6160501 o=8192 (6)
--2633:1:aspacem 21: file 000483c000-0004845fff 40960 r-x-- d=0x00c
i=6160503 o=0 (7)
--2633:1:aspacem 22: anon 0004846000-000484cfff 28672 -----
--2633:1:aspacem 23: file 000484d000-000484dfff 4096 rw--- d=0x00c
i=6160503 o=36864 (7)
--2633:1:aspacem 24: file 000484e000-00048d5fff 557056 r-x-- d=0x00c
i=6160509 o=0 (8)
--2633:1:aspacem 25: anon 00048d6000-00048dcfff 28672 -----
--2633:1:aspacem 26: file 00048dd000-00048defff 8192 rw--- d=0x00c
i=6160509 o=552960 (8)
--2633:1:aspacem 27: anon 00048df000-00048e3fff 20480 rw---
--2633:1:aspacem 28: 00048e4000-0037ffffff 823m
--2633:1:aspacem 29: FILE 0038000000-0038057fff 360448 r-x-- d=0x00c
i=6947992 o=0 (0)
--2633:1:aspacem 30: file 0038058000-0038058fff 4096 r-x-- d=0x00c
i=6947992 o=360448 (0)
--2633:1:aspacem 31: FILE 0038059000-00383cffff 3633152 r-x-- d=0x00c
i=6947992 o=364544 (0)
--2633:1:aspacem 32: FILE 00383d0000-00383d4fff 20480 rw--- d=0x00c
i=6947992 o=3997696 (0)
--2633:1:aspacem 33: ANON 00383d5000-0039500fff 17m rw---
--2633:1:aspacem 34: 0039501000-006159dfff 640m
--2633:1:aspacem 35: RSVN 006159e000-006159efff 4096 ----- SmFixed
--2633:1:aspacem 36: ANON 006159f000-0062139fff 11m rwx--
--2633:1:aspacem 37: 006213a000-006213bfff 8192
--2633:1:aspacem 38: FILE 006213c000-006213cfff 4096 rw--- d=0x00e
i=2198 o=0 (3)
--2633:1:aspacem 39: ANON 006213d000-0062164fff 163840 rwx--
--2633:1:aspacem 40: 0062165000-0062219fff 741376
--2633:1:aspacem 41: ANON 006221a000-0062319fff 1048576 rwx--
--2633:1:aspacem 42: ANON 006231a000-006231bfff 8192 -----
--2633:1:aspacem 43: ANON 006231c000-006241bfff 1048576 rwx--
--2633:1:aspacem 44: ANON 006241c000-006241dfff 8192 -----
--2633:1:aspacem 45: 006241e000-006250efff 987136
--2633:1:aspacem 46: ANON 006250f000-006274dfff 2355200 rwx--
--2633:1:aspacem 47: 006274e000-00628f7fff 1744896
--2633:1:aspacem 48: ANON 00628f8000-0064fa6fff 38m rwx--
--2633:1:aspacem 49: 0064fa7000-00bd33cfff 1411m
--2633:1:aspacem 50: RSVN 00bd33d000-00bdb3afff 8380416 ----- SmUpper
--2633:1:aspacem 51: anon 00bdb3b000-00bdb3cfff 8192 rw---
--2633:1:aspacem 52: 00bdb3d000-00beb1bfff 15m
--2633:1:aspacem 53: ANON 00beb1c000-00beb3cfff 135168 rw---
--2633:1:aspacem 54: RSVN 00beb3d000-00fffeffff 1044m ----- SmFixed
--2633:1:aspacem 55: anon 00ffff0000-00ffff0fff 4096 r-x--
--2633:1:aspacem 56: RSVN 00ffff1000-00ffffffff 61440 ----- SmFixed
--2633:1:aspacem >>>
==2633==
==2633== HEAP SUMMARY:
==2633== in use at exit: 0 bytes in 0 blocks
==2633== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==2633==
==2633== All heap blocks were freed -- no leaks are possible
==2633==
==2633== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==2633== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
--2633:1:gdbsrv VG core calling VG_(gdbserver_exit) tid 1 will exit
--2633:1:gdbsrv not connected
--2633:1:gdbsrv remote_finish (reason orderly_finish) 1030 -1
--2633:1:gdbsrv 2633 (creator 2633) maybe unlinking
/tmp/vgdb-pipe-from-vgdb-to-2633-by-root-on-???
/tmp/vgdb-pipe-to-vgdb-from-2633-by-root-on-???
/tmp/vgdb-pipe-shared-mem-vgdb-2633-by-root-on-???
--2633:1:core_os VG_(terminate_NORETURN)(tid=1)
Supervisor has crashed at Thu Jan 1 08:10:47 EST 1970, exit code 255
|
|
From: Mikhail B. <mik...@de...> - 2014-12-11 11:48:16
|
On 12/05/2014 09:26 PM, Philippe Waroquiers wrote: > On Thu, 2014-12-04 at 16:16 +0300, Mikhail Baikov wrote: > >> And the crash... I'm sorry it's not a segfault. It's a crash. >> One of the strange things is that inspite of --run-libc-freeres set no >> in the log appears >> /bin/sh: symbol '__libc_freeres': can't resolve symbol and the rest... > This is I suppose because valgrind has not been properly compiled > for ulibc. > If you look in coregrind/vg_preloaded.c, you will see that if symbol > __UCLIBC__ is defined, then no calls to __libc_freeres(); > will be generated. > So, that looks a first problem to solve : I guess you should > ensure that __UCLIBC__ is defined when you compile on the host, > and ensure to compile with the relevant uclibc headers files at > the host side. > > Yeah. Raising __UCLIBC__ flag (export CFLAGS="-D__UCLIBC__") has helped but it seems to me that this flag will never be raised in normal conditions. Searching this flag among sources I found no place where it's defined. $ grep -R "__UCLIBC__" ./valgrind-3.10.1/* ./valgrind-3.10.1/coregrind/vg_preloaded.c:# if !defined(__UCLIBC__) \ ./valgrind-3.10.1/coregrind/m_debuginfo/minilzo-inl.c:#elif defined(__UCLIBC__) && defined(__UCLIBC_MAJOR__) && defined(__UCLIBC_MINOR__) ./valgrind-3.10.1/coregrind/m_debuginfo/lzodefs.h:#elif defined(__UCLIBC__) && defined(__UCLIBC_MAJOR__) && defined(__UCLIBC_MINOR__) |
|
From: Philippe W. <phi...@sk...> - 2014-12-13 14:59:20
|
On Thu, 2014-12-11 at 14:48 +0300, Mikhail Baikov wrote: > On 12/05/2014 09:26 PM, Philippe Waroquiers wrote: > > On Thu, 2014-12-04 at 16:16 +0300, Mikhail Baikov wrote: > > > >> And the crash... I'm sorry it's not a segfault. It's a crash. > >> One of the strange things is that inspite of --run-libc-freeres set no > >> in the log appears > >> /bin/sh: symbol '__libc_freeres': can't resolve symbol and the rest... > > This is I suppose because valgrind has not been properly compiled > > for ulibc. > > If you look in coregrind/vg_preloaded.c, you will see that if symbol > > __UCLIBC__ is defined, then no calls to __libc_freeres(); > > will be generated. > > So, that looks a first problem to solve : I guess you should > > ensure that __UCLIBC__ is defined when you compile on the host, > > and ensure to compile with the relevant uclibc headers files at > > the host side. > > > > > Yeah. Raising __UCLIBC__ flag (export CFLAGS="-D__UCLIBC__") has helped > but it seems to me that this flag will never be raised in normal > conditions. Searching this flag among sources I found no place where > it's defined. > $ grep -R "__UCLIBC__" ./valgrind-3.10.1/* > ./valgrind-3.10.1/coregrind/vg_preloaded.c:# if !defined(__UCLIBC__) \ > ./valgrind-3.10.1/coregrind/m_debuginfo/minilzo-inl.c:#elif > defined(__UCLIBC__) && defined(__UCLIBC_MAJOR__) && > defined(__UCLIBC_MINOR__) > ./valgrind-3.10.1/coregrind/m_debuginfo/lzodefs.h:#elif > defined(__UCLIBC__) && defined(__UCLIBC_MAJOR__) && > defined(__UCLIBC_MINOR__) > Yes, it looks like uclibc is not detected during configure time. So, you have to set this flag yourself. Philippe |
Thanks for helping keep SourceForge clean.
X