| Summary: | valgrind does not resolve symbols in binaries which have been loaded twice in a program through dlmopen | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | mathieu.lacage |
| Component: | general | Assignee: | Julian Seward <jseward> |
| Status: | REPORTED --- | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version: | 3.6 SVN | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Attachments: |
tarball contains reduced test source code and makefile.
patch which fixes this bug |
||
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.
|
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)