Bug 311093 - massif and memcheck fail to redirect malloc calls on statically linked application
Summary: massif and memcheck fail to redirect malloc calls on statically linked applic...
Status: RESOLVED WORKSFORME
Alias: None
Product: valgrind
Classification: Developer tools
Component: general (show other bugs)
Version: 3.8.0
Platform: unspecified Unspecified
: NOR normal
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-12-03 16:21 UTC by Tyson Wiser
Modified: 2023-02-11 03:52 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
tgz file containing text output (35.32 KB, application/octet-stream)
2012-12-03 16:26 UTC, Tyson Wiser
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tyson Wiser 2012-12-03 16:21:37 UTC
> 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).
Comment 1 Tyson Wiser 2012-12-03 16:26:19 UTC
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'
Comment 2 Philippe Waroquiers 2012-12-06 23:26:02 UTC
(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 ?
Comment 3 Tyson Wiser 2012-12-13 15:42:12 UTC
(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.
Comment 4 Tom Hughes 2012-12-13 16:09:17 UTC
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.
Comment 5 Philippe Waroquiers 2012-12-16 13:52:59 UTC
(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
Comment 6 Tyson Wiser 2012-12-17 16:36:56 UTC
(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.
Comment 7 Philippe Waroquiers 2012-12-17 23:09:21 UTC
(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.
Comment 8 Paul Floyd 2023-01-12 16:29:06 UTC
Setting this as waitingforinfo as we never got a full reply.
Comment 9 Bug Janitor Service 2023-01-27 05:07:15 UTC
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!
Comment 10 Bug Janitor Service 2023-02-11 03:52:04 UTC
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!