> uname -a Linux twiser-d-01.localdomain 2.6.18-308.11.1.el5 #1 SMP Tue Jul 10 08:48:43 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux I have a statically linked 64-bit application running on 64-bit CentOS 5.8. When running massif or memcheck (using a built-from-source valgrind-3.8.1 and the '--soname-synonyms=somalloc=NONE' option) on the application it fails to redirect malloc calls. The redirection succeeds for both tools when run on the static_malloc test. Mailing list conversation can be found here: http://thread.gmane.org/gmane.comp.debugging.valgrind/12653 As requested, I will attach the output of both the massif and memcheck tool runs using the '-v -v -v -d -d -d --trace-redir=yes' options as well as the massif.out.<pid> file and the output of 'nm MyProg | grep malloc'. Reproducible: Always Steps to Reproduce: 1. Compile my application 2. Run 'valgrind --tool=[massif|memcheck] --soname-synonyms=somalloc=NONE ./MyProg' Actual Results: See attached massif.out.6492, massif-verbose.out, and memcheck.verbose.out files. Expected Results: A valid heap profile (I'm mainly concerned with massif output, memcheck was included due to debugging steps performed in the mailing list thread).
Created attachment 75607 [details] tgz file containing text output Contains the following files: * massif.out.6492 - regular massif output file * massif-verbose.out - massif output using '-v -v -v -d -d -d --trace-redir=yes' options * memcheck-verbose.out - memcheck output using '-v -v -v -d -d -d --trace-redir=yes' options * nm-grep-malloc.out - output of 'nm MyProg | grep malloc'
(In reply to comment #0) > > uname -a > Linux twiser-d-01.localdomain 2.6.18-308.11.1.el5 #1 SMP Tue Jul 10 08:48:43 > EDT 2012 x86_64 x86_64 x86_64 GNU/Linux > > I have a statically linked 64-bit application running on 64-bit CentOS 5.8. Effectively, redirection (needing or not --soname-synonyms) are not working in "fully static" executable, as a "working" LD_PRELOAD is needed to have redirection working. What is strange is that the trace you have attached shows that there are some dynamic libs e.g. --6519:1:aspacem ( 0) /home/twiser/programs/valgrind-3.8.1/lib/valgrind/memcheck-amd64-linux --6519:1:aspacem ( 1) /mnt/storage/twiser/code/MyProg/trunk/build-linux/src/MyProg --6519:1:aspacem ( 2) /tmp/vgdb-pipe-shared-mem-vgdb-6519-by-twiser-on-twiser-d-01.logostech.net --6519:1:aspacem ( 3) /usr/lib/locale/locale-archive --6519:1:aspacem ( 4) /usr/lib64/gconv/gconv-modules.cache --6519:1:aspacem ( 6) /lib64/libnss_files-2.5.so --6519:1:aspacem ( 7) /lib64/libc-2.5.so --6519:1:aspacem ( 8) /lib64/ld-2.5.so So, it is not very clear if MyProg is effectively a static executable (it does not look like). What is ldd MyProg giving ? Maybe export LD_DEBUG=all before valgrind ... will explain what is going on ? (comparing the behaviour when valgrind-ing static_malloc and MyProg) In particular, why are /home/twiser/programs/valgrind-3.8.1/lib/valgrind/vgpreload_core-amd64-linux.so:/home/twiser/programs/valgrind-3.8.1/lib/valgrind/vgpreload_memcheck-amd64-linux.so (which are in preload_string shown in the trace) not LD_PRELOADed ?
(In reply to comment #2) > So, it is not very clear if MyProg is effectively a static executable (it > does not look like). > What is > ldd MyProg > giving ? It gives "not a dynamic executable". > Maybe > export LD_DEBUG=all > before valgrind ... > will explain what is going on ? I will try to find some time to test this soon. > (comparing the behaviour when valgrind-ing > static_malloc > and > MyProg) > In particular, why are > /home/twiser/programs/valgrind-3.8.1/lib/valgrind/vgpreload_core-amd64-linux. > so:/home/twiser/programs/valgrind-3.8.1/lib/valgrind/vgpreload_memcheck- > amd64-linux.so > (which are in preload_string shown in the trace) not LD_PRELOADed ? I'm not knowledgeable enough about valgrind or LD_PRELOAD to comment on this.
A statically linked executable will not invoke the dynamic linker at all, which means the preload libraries that define the overrides for malloc etc will not be processed. Basically, don't try and use valgrind on statically linked programs because it isn't going to be able to give you very useful results - even if you normally link statically, build a dynamically linked version for the purposes of running valgrind.
(In reply to comment #4) > A statically linked executable will not invoke the dynamic linker at all, > which means the preload libraries that define the overrides for malloc etc > will not be processed. I do not understand what this executable is. ldd tells it is a static executable, but aspacemgr shows a.o. the following: --6519:1:aspacem ( 6) /lib64/libnss_files-2.5.so --6519:1:aspacem ( 7) /lib64/libc-2.5.so --6519:1:aspacem ( 8) /lib64/ld-2.5.so
(In reply to comment #3) > > Maybe > > export LD_DEBUG=all > > before valgrind ... > > will explain what is going on ? > > I will try to find some time to test this soon. I haven't yet had time to try this but I have discovered that if I use the '--pages-as-heap=yes' option then I get results. Without that option I get nothing. That appears to be the case whether or not the executable is fully static or partially dynamic.
(In reply to comment #6) > I haven't yet had time to try this but I have discovered that if I use the > '--pages-as-heap=yes' option then I get results. Without that option I get > nothing. That appears to be the case whether or not the executable is fully > static or partially dynamic. I think --pages-as-heap does not need to intercept the malloc functions : it just needs to look at syscalls (which do not need function replacements/interception). What I do not understand is that ldd shows that your executable is a static executable, but still it has a bunch of ".so" loaded.
Setting this as waitingforinfo as we never got a full reply.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!