Bug 243153 - valgrind does not resolve symbols in binaries which have been loaded twice in a program through dlmopen
Summary: valgrind does not resolve symbols in binaries which have been loaded twice in...
Status: REPORTED
Alias: None
Product: valgrind
Classification: Developer tools
Component: general (show other bugs)
Version: 3.6 SVN
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-06-29 13:42 UTC by mathieu.lacage
Modified: 2010-06-29 13:44 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments
tarball contains reduced test source code and makefile. (673 bytes, application/octet-stream)
2010-06-29 13:42 UTC, mathieu.lacage
Details
patch which fixes this bug (1.84 KB, patch)
2010-06-29 13:44 UTC, mathieu.lacage
Details

Note You need to log in before you can comment on or make changes to this bug.
Description mathieu.lacage 2010-06-29 13:42:35 UTC
Created attachment 48453 [details]
tarball contains reduced test source code and makefile.

Version:           3.6 SVN
OS:                Linux

The attached testcase shows what happens if you use dlmopen to load the same elf binary twice in the same process at different base addresses (yes, it's possible with the right arguments to this function). to summarize, valgrind does not know how to resolve symbols in the second version of the binary while it knows perfectly how to resolve symbols in the first version of the binary.


Reproducible: Always

Steps to Reproduce:
tar jxf test.tar.gz
cd test
make
valgrind ./test b

Actual Results:  
==9277==    at 0x55A9567: ??? (in /home/mathieu/test/libtest.so)
==9277==    by 0x400640: call (test.c:9)
==9277==    by 0x400717: main (test.c:34)


Expected Results:  
==9272==    at 0x502F567: bar (libtest.c:8)
==9272==    by 0x400640: call (test.c:9)
==9272==    by 0x4006F3: main (test.c:29)
Comment 1 mathieu.lacage 2010-06-29 13:44:34 UTC
Created attachment 48454 [details]
patch which fixes this bug

This patch makes sure to create two separate debugging information entries in the list of debuginfo if the same binary file is mmaped twice with with a different base address.