|
From: Ivo R. <iv...@iv...> - 2015-11-26 17:52:50
|
Hi Mark,
Thank you again for having me helped understand the impact
of your changes from r15726 (intercept somalloc functions).
In addition to commit r15728, on Solaris, this change somehow impacted the
ability to print a correct stacktrace for intercepted memalign().
For example test case memcheck/tests/test-plo-no previously showed:
Address 0x7ff706360 is 0 bytes inside a block of size 5 alloc'd
at 0x7FFB04ED2: memalign (vg_replace_malloc.c:450)
by 0x401304: memalign16 (malloc.h:21)
by 0x4014E2: main (test-plo.c:49)
While now it shows only:
Address 0x7ff706360 is 0 bytes inside a block of size 5 alloc'd
at 0x7FFB04ED2: memalign (vgpreload_memcheck-amd64-solaris.so)
by 0x401304: memalign16 (malloc.h:21)
by 0x4014E2: main (test-plo.c:49)
I investigated the differences on Solaris and Linux and see the following
dubious information in the verbose log (-v -v -v) when executing:
./vg-in-place --partial-loads-ok=no -v -v -v ./memcheck/tests/test-plo
==12622== Adding active redirection:
--12622-- new: 0x04ebcd80 (memalign ) R-> (1011.0) 0x04c2dead memalign
==12622== Ignoring duplicate redirection:
--12622-- old: 0x04ebcd80 (memalign ) R-> (1011.0) 0x04c2dead memalign
--12622-- new: 0x04ebcd80 (memalign ) R-> (1011.0) 0x04c2dcce memalign
This duplicate redirection for memalign was not present before r15726 and I
don't know where it is coming from. I think it is the reason why the
stacktrace cannot be described correctly because address of the new
redirection cannot be mapped to the debug info.
On Linux Ubuntu, test-plo is using the following libraries:
/lib/x86_64-linux-gnu/ld-2.21.so
vgpreload_core-amd64-linux.so
vgpreload_memcheck-amd64-linux.so
/lib/x86_64-linux-gnu/libc-2.21.so
And I see the following *memalign* symbols there:
$ nm /usr/lib/debug/lib/x86_64-linux-gnu/ld-2.21.so | grep memalign
0000000000018af0 W __libc_memalign
$ nm /usr/lib/debug/lib/x86_64-linux-gnu/libc-2.21.so | grep memalign
0000000000084d80 t __GI___libc_memalign
00000000000833f0 t _int_memalign
0000000000084d80 T __libc_memalign
0000000000084d80 W memalign
0000000000084d80 t __memalign
0000000000083610 t memalign_check
0000000000087f70 t memalignhook
00000000003c4bc0 V __memalign_hook
0000000000086030 t memalign_hook_ini
00000000003c6a68 b old_memalign_hook
0000000000087310 t __posix_memalign
0000000000087310 W posix_memalign
0000000000088d70 t tr_memalignhook
00000000003c6a88 b tr_old_memalign_hook
$ nm vgpreload_memcheck-amd64-linux.so | grep memalign
0000000000005cce T _vgr10110ZU_libcZdsoZa_memalign
0000000000005ead T _vgr10110ZU_VgSoSynsomalloc_memalign
0000000000005e21 T _vgr10160ZU_libcZdsoZa_posix_memalign
0000000000005e67 T _vgr10160ZU_VgSoSynsomalloc_posix_memalign
Surprisingly, for e.g. posix_memalign() I do not see any "duplicate
redirection".
What could be wrong and what could be possible hypothesis?
Kind regards,
I.
|
|
From: Mark W. <mj...@re...> - 2015-11-26 19:36:44
|
On Thu, Nov 26, 2015 at 06:52:42PM +0100, Ivo Raisr wrote: > For example test case memcheck/tests/test-plo-no previously showed: > > Address 0x7ff706360 is 0 bytes inside a block of size 5 alloc'd > at 0x7FFB04ED2: memalign (vg_replace_malloc.c:450) > by 0x401304: memalign16 (malloc.h:21) > by 0x4014E2: main (test-plo.c:49) > > While now it shows only: > Address 0x7ff706360 is 0 bytes inside a block of size 5 alloc'd > at 0x7FFB04ED2: memalign (vgpreload_memcheck-amd64-solaris.so) > by 0x401304: memalign16 (malloc.h:21) > by 0x4014E2: main (test-plo.c:49) So, the addresses are exactly the same, but for the address in vgpreload_memcheck-amd64-solaris.so no source line can be found? I am not sure how a change in symbol redirection can cause that. Does --debug-dump=line give any hints/differences? Cheers, Mark |
|
From: Ivo R. <iv...@iv...> - 2015-11-27 22:15:18
|
2015-11-26 20:36 GMT+01:00 Mark Wielaard <mj...@re...>: > On Thu, Nov 26, 2015 at 06:52:42PM +0100, Ivo Raisr wrote: > > For example test case memcheck/tests/test-plo-no previously showed: > > > > Address 0x7ff706360 is 0 bytes inside a block of size 5 alloc'd > > at 0x7FFB04ED2: memalign (vg_replace_malloc.c:450) > > by 0x401304: memalign16 (malloc.h:21) > > by 0x4014E2: main (test-plo.c:49) > > > > While now it shows only: > > Address 0x7ff706360 is 0 bytes inside a block of size 5 alloc'd > > at 0x7FFB04ED2: memalign (vgpreload_memcheck-amd64-solaris.so) > > by 0x401304: memalign16 (malloc.h:21) > > by 0x4014E2: main (test-plo.c:49) > > So, the addresses are exactly the same, but for the address in > vgpreload_memcheck-amd64-solaris.so no source line can be found? > > I am not sure how a change in symbol redirection can cause that. > Does --debug-dump=line give any hints/differences? > Yes, no source line can be found, just symbol name and soname. After some debugging and tracing, I found out that a loctab entry for this symbol (_vgr10110ZU_VgSoSynsomalloc_memalign) has size only 17 bytes. This means that ML_(search_one_loctab)() returns -1 (not found) which results in no source line. However debuginfo (and also readelf/elfdump) shows that size should be 225 bytes. So I will dig more into how that could be possible. Thank you for the hints provided and stay tuned... I. |