|
From: Wiser, T. <TW...@lo...> - 2012-11-26 20:46:29
|
I am developing a 64-bit C++ application on 64-bit CentOS 5.8 using the standard CentOS packages (gcc 4.4.6, not 4.1.2). It has been compiled with debug information. When I try profiling it with massif I always get the following in the massif.out.XXXX file using the command 'valgrind --tool=massif ./MyProg': ********** Begin massif.out.XXXX ********** desc: (none) cmd: ./MyProg time_unit: i #----------- snapshot=0 #----------- time=0 mem_heap_B=0 mem_heap_extra_B=0 mem_stacks_B=0 heap_tree=empty ********** End massif.out.XXXX ********** I have tried various combinations of options to massif with no change in the results. Since CentOS is using valgrind 3.5.0 I even tried downloading and compiling 3.8.1, but that produced the same results as well. I finally ended up trying 'valgrind --tool=massif ls -l' and it appeared to work properly (i.e. it produced multiple snapshots that had non-zero memory use). I have tried every combination of search keywords I can think of on Google and can't find any reports of similar problems. Does anyone have any idea what I am doing wrong? I am new to valgrind so I'm sure it is something simple that I have missed. It's probably not relevant, but just in case, I have been able to run memcheck against my program without any problems. I have not tried any of the other valgrind tools. Thanks, Tyson |
|
From: Wiser, T. <TW...@lo...> - 2012-11-27 20:43:23
|
>From a question on stackoverflow (http://stackoverflow.com/questions/13588474/valgrinds-massif-tool-will-not-profile-my-application) it was pointed out that statically linking the application was causing the problem. I was able to do a partial dynamic link to resolve the issue. |
|
From: Philippe W. <phi...@sk...> - 2012-11-27 22:35:26
|
On Mon, 2012-11-26 at 12:46 -0800, Wiser, Tyson wrote: > Does anyone have any idea what I am doing wrong? I am new to valgrind > so I'm sure it is something simple that I have missed. Not too sure it is very simple. Normally, massif should work with default args. Maybe there is a problem with malloc replacement ? Can you try (with 3.8.1) to launch valgrind --tool=massif --stats=yes --trace-malloc=yes ... your app ... and then the same using ls as app. and see if there are some relevant differences (like no indication that malloc looks replaced in your app). Philippe |
|
From: Philippe W. <phi...@sk...> - 2012-11-28 18:07:45
|
On Tue, 2012-11-27 at 23:35 +0100, Philippe Waroquiers wrote: > On Mon, 2012-11-26 at 12:46 -0800, Wiser, Tyson wrote: > > > Does anyone have any idea what I am doing wrong? I am new to valgrind > > so I'm sure it is something simple that I have missed. I just saw your follow-up telling you have a statically linked library. >From Valgrind 3.8.1 onwards, Valgrind can properly work with statically linked malloc libraries thanks to the option --soname-synonyms=somalloc=NONE This option can also be used to support alternative malloc libraries such as tcmalloc. See user manual for details. I will update Valgrind FAQ with the above information. Philippe |
|
From: Wiser, T. <TW...@lo...> - 2012-11-28 19:06:57
|
>From Valgrind 3.8.1 onwards, Valgrind can properly work with >statically linked malloc libraries thanks to the option > --soname-synonyms=somalloc=NONE > >This option can also be used to support alternative malloc libraries >such as tcmalloc. See user manual for details. > >I will update Valgrind FAQ with the above information. Does this need to be combined with any other option to work? I tried it with 3.8.1 that I built locally and got the same result (i.e. no profile). The command I used was: valgrind --tool=massif --soname-synonyms=somalloc=NONE ./MyProg |
|
From: Philippe W. <phi...@sk...> - 2012-11-28 21:34:44
|
On Wed, 2012-11-28 at 11:06 -0800, Wiser, Tyson wrote: > I tried it with 3.8.1 that I built locally and got the same result > (i.e. no profile). The command I used was: > > valgrind --tool=massif --soname-synonyms=somalloc=NONE ./MyProg The above is supposed to properly replace a static malloc. I tried this with the Valgrind regression test, and it works. When adding a -v option, succesful replacements are giving lines such as: --13571-- REDIR: 0x80483c4 (malloc) redirected to 0x4005fc5 (malloc) --13571-- REDIR: 0x80483e3 (free) redirected to 0x40059ec (free) Can you try with -v and/or with --trace-redir=yes ? That might give some lights about the problem ? Philippe |
|
From: Wiser, T. <TW...@lo...> - 2012-11-29 15:33:42
|
>Can you try with -v and/or with --trace-redir=yes ? >That might give some lights about the problem ? I used both options and it produced the following output. Thanks for taking the time to look at this. ==9674== Massif, a heap profiler ==9673== Copyright (C) 2003-2012, and GNU GPL'd, by Nicholas Nethercote ==9673== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==9673== Command: ./MyProg ==9673== --9673-- Valgrind options: --9673-- --tool=massif --9673-- --soname-synonyms=somalloc=NONE --9673-- --trace-redir=yes --9673-- -v --9673-- Contents of /proc/version: --9673-- Linux version 2.6.18-308.11.1.el5 (moc...@bu...) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-52)) #1 SMP Tue Jul 10 08:48:43 EDT 2012 --9673-- Arch and hwcaps: AMD64, amd64-sse3-cx16 --9673-- Page sizes: currently 4096, max supported 4096 --9673-- Valgrind library directory: /home/twiser/programs/valgrind-3.8.1/lib/valgrind --9673-- Massif: alloc-fns: --9673-- Massif: malloc --9673-- Massif: __builtin_new --9673-- Massif: operator new(unsigned) --9673-- Massif: operator new(unsigned long) --9673-- Massif: __builtin_vec_new --9673-- Massif: operator new[](unsigned) --9673-- Massif: operator new[](unsigned long) --9673-- Massif: calloc --9673-- Massif: realloc --9673-- Massif: memalign --9673-- Massif: posix_memalign --9673-- Massif: valloc --9673-- Massif: operator new(unsigned, std::nothrow_t const&) --9673-- Massif: operator new[](unsigned, std::nothrow_t const&) --9673-- Massif: operator new(unsigned long, std::nothrow_t const&) --9673-- Massif: operator new[](unsigned long, std::nothrow_t const&) --9673-- Massif: ignore-fns: --9673-- Massif: <empty> --9673-- << --9673-- ------ REDIR STATE after VG_(redir_initialise) ------ --9673-- ------ ACTIVE ------ --9673-- 0xffffffffff600000 (??? ) R-> (0000.0) 0x3801c013 ??? --9673-- 0xffffffffff600400 (??? ) R-> (0000.0) 0x3801c01d ??? --9673-- 0xffffffffff600800 (??? ) R-> (0000.0) 0x3801c027 ??? --9673-- >> --9673-- Reading syms from /home/twiser/code/MyProg/build/MyProg --9673-- svma 0x0000400190, avma 0x0000400190 --9673-- object doesn't have a dynamic symbol table --9673-- warning: DiCfSI 0x1f80056b2f0 .. 0x1f80056b442 outside mapped rw segments (NONE) --9673-- warning: DiCfSI 0x1f80056b443 .. 0x1f80056b444 outside mapped rw segments (NONE) --9673-- warning: DiCfSI 0x1f80056b445 .. 0x1f80056b445 outside mapped rw segments (NONE) --9673-- warning: DiCfSI 0x2900056b4f0 .. 0x2900056b4f1 outside mapped rw segments (NONE) --9673-- warning: DiCfSI 0x2900056b4f2 .. 0x2900056b4f5 outside mapped rw segments (NONE) --9673-- warning: DiCfSI 0x2900056b4f6 .. 0x2900056b6d6 outside mapped rw segments (NONE) --9673-- warning: DiCfSI 0x2900056b6d7 .. 0x2900056b6d8 outside mapped rw segments (NONE) --9673-- warning: DiCfSI 0x2900056b6d9 .. 0x2900056b6da outside mapped rw segments (NONE) --9673-- warning: DiCfSI 0x2900056b6db .. 0x2900056b6dc outside mapped rw segments (NONE) --9673-- warning: DiCfSI 0x2900056b6dd .. 0x2900056b6dd outside mapped rw segments (NONE) --9673-- << --9673-- ------ REDIR STATE after VG_(redir_notify_new_DebugInfo) ------ --9673-- TOPSPECS of soname NONE filename /home/twiser/code/MyProg/build/MyProg --9673-- ------ ACTIVE ------ --9673-- 0xffffffffff600000 (??? ) R-> (0000.0) 0x3801c013 ??? --9673-- 0xffffffffff600400 (??? ) R-> (0000.0) 0x3801c01d ??? --9673-- 0xffffffffff600800 (??? ) R-> (0000.0) 0x3801c027 ??? --9673-- >> --9673-- Reading syms from /home/twiser/programs/valgrind-3.8.1/lib/valgrind/massif-amd64-linux --9673-- svma 0x0038000000, avma 0x0038000000 --9673-- object doesn't have a dynamic symbol table --9673-- << --9673-- ------ REDIR STATE after VG_(redir_notify_new_DebugInfo) ------ --9673-- TOPSPECS of soname NONE filename /home/twiser/programs/valgrind-3.8.1/lib/valgrind/massif-amd64-linux --9673-- TOPSPECS of soname NONE filename /home/twiser/code/MyProg/build/MyProg --9673-- ------ ACTIVE ------ --9673-- 0xffffffffff600000 (??? ) R-> (0000.0) 0x3801c013 vgPlain_amd64_linux_REDIR_FOR_vgettimeofday --9673-- 0xffffffffff600400 (??? ) R-> (0000.0) 0x3801c01d vgPlain_amd64_linux_REDIR_FOR_vtime --9673-- 0xffffffffff600800 (??? ) R-> (0000.0) 0x3801c027 vgPlain_amd64_linux_REDIR_FOR_vgetcpu --9673-- >> --9673-- Scheduler: using generic scheduler lock implementation. ==9673== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-9673-by-twiser-on-twiser-d-01 ==9673== embedded gdbserver: writing to /tmp/vgdb-pipe-to-vgdb-from-9673-by-twiser-on-twiser-d-01 ==9673== embedded gdbserver: shared mem /tmp/vgdb-pipe-shared-mem-vgdb-9673-by-twiser-on-twiser-d-01 ==9673== ==9673== TO CONTROL THIS PROCESS USING vgdb (which you probably ==9673== don't want to do, unless you know exactly what you're doing, ==9673== or are doing some strange experiment): ==9673== /home/twiser/programs/valgrind-3.8.1/lib/valgrind/../../bin/vgdb --pid=9673 ...command... ==9673== ==9673== TO DEBUG THIS PROCESS USING GDB: start GDB like this ==9673== /path/to/gdb ./MyProg ==9673== and then give GDB the following command ==9673== target remote | /home/twiser/programs/valgrind-3.8.1/lib/valgrind/../../bin/vgdb --pid=9673 ==9673== --pid is optional if only one valgrind process is running ==9673== --9673-- REDIR: 0xffffffffff600400 (???) redirected to 0x3801c01d (vgPlain_amd64_linux_REDIR_FOR_vtime) --9673-- REDIR: 0xffffffffff600000 (???) redirected to 0x3801c013 (vgPlain_amd64_linux_REDIR_FOR_vgettimeofday) --9673-- Reading syms from /lib64/libnss_files-2.5.so --9673-- svma 0x0000001fe0, avma 0x0007deffe0 --9673-- << --9673-- ------ REDIR STATE after VG_(redir_notify_new_DebugInfo) ------ --9673-- TOPSPECS of soname libnss_files.so.2 filename /lib64/libnss_files-2.5.so --9673-- TOPSPECS of soname NONE filename /home/twiser/programs/valgrind-3.8.1/lib/valgrind/massif-amd64-linux --9673-- TOPSPECS of soname NONE filename /home/twiser/code/MyProg/build/MyProg --9673-- ------ ACTIVE ------ --9673-- 0xffffffffff600000 (??? ) R-> (0000.0) 0x3801c013 vgPlain_amd64_linux_REDIR_FOR_vgettimeofday --9673-- 0xffffffffff600400 (??? ) R-> (0000.0) 0x3801c01d vgPlain_amd64_linux_REDIR_FOR_vtime --9673-- 0xffffffffff600800 (??? ) R-> (0000.0) 0x3801c027 vgPlain_amd64_linux_REDIR_FOR_vgetcpu --9673-- >> --9673-- Reading syms from /lib64/libc-2.5.so --9673-- svma 0x000001d780, avma 0x0008016780 --9673-- << --9673-- ------ REDIR STATE after VG_(redir_notify_new_DebugInfo) ------ --9673-- TOPSPECS of soname libc.so.6 filename /lib64/libc-2.5.so --9673-- TOPSPECS of soname libnss_files.so.2 filename /lib64/libnss_files-2.5.so --9673-- TOPSPECS of soname NONE filename /home/twiser/programs/valgrind-3.8.1/lib/valgrind/massif-amd64-linux --9673-- TOPSPECS of soname NONE filename /home/twiser/code/MyProg/build/MyProg --9673-- ------ ACTIVE ------ --9673-- 0xffffffffff600000 (??? ) R-> (0000.0) 0x3801c013 vgPlain_amd64_linux_REDIR_FOR_vgettimeofday --9673-- 0xffffffffff600400 (??? ) R-> (0000.0) 0x3801c01d vgPlain_amd64_linux_REDIR_FOR_vtime --9673-- 0xffffffffff600800 (??? ) R-> (0000.0) 0x3801c027 vgPlain_amd64_linux_REDIR_FOR_vgetcpu --9673-- >> --9673-- Reading syms from /lib64/ld-2.5.so --9673-- svma 0x0000000a70, avma 0x0008350a70 --9673-- << --9673-- ------ REDIR STATE after VG_(redir_notify_new_DebugInfo) ------ --9673-- TOPSPECS of soname ld-linux-x86-64.so.2 filename /lib64/ld-2.5.so --9673-- TOPSPECS of soname libc.so.6 filename /lib64/libc-2.5.so --9673-- TOPSPECS of soname libnss_files.so.2 filename /lib64/libnss_files-2.5.so --9673-- TOPSPECS of soname NONE filename /home/twiser/programs/valgrind-3.8.1/lib/valgrind/massif-amd64-linux --9673-- TOPSPECS of soname NONE filename /home/twiser/code/MyProg/build/MyProg --9673-- ------ ACTIVE ------ --9673-- 0xffffffffff600000 (??? ) R-> (0000.0) 0x3801c013 vgPlain_amd64_linux_REDIR_FOR_vgettimeofday --9673-- 0xffffffffff600400 (??? ) R-> (0000.0) 0x3801c01d vgPlain_amd64_linux_REDIR_FOR_vtime --9673-- 0xffffffffff600800 (??? ) R-> (0000.0) 0x3801c027 vgPlain_amd64_linux_REDIR_FOR_vgetcpu --9673-- >> ==9673== |
|
From: Philippe W. <phi...@sk...> - 2012-11-29 23:01:24
|
On Thu, 2012-11-29 at 07:30 -0800, Wiser, Tyson wrote: > >Can you try with -v and/or with --trace-redir=yes ? > >That might give some lights about the problem ? > > I used both options and it produced the following output. Thanks for taking the time to look at this. There is an unexpected (or rather missing) behaviour in the trace you have provided. You should find lines such as: --3143-- Reading syms from /home/philippe/valgrind/valgrind-3.8.1/install/lib/valgrind/vgpreload_core-amd64-linux.so ... --3143-- Reading syms from /home/philippe/valgrind/valgrind-3.8.1/install/lib/valgrind/vgpreload_massif-amd64-linux.so Without these, there is no chance to have replacements being done. Maybe an installation problem ? Can you try: valgrind --tool=massif --soname-synonyms=somalloc=NONE --trace-redir=yes \ -v -v -v -d -d -d ./MyProg 2>&1 | grep -i preload This should give something like: --31179:2:initimg preload_string: --31179:2:initimg "/home/philippe/valgrind/valgrind-3.8.1/install/lib/valgrind/vgpreload_core-amd64-linux.so:/home/philippe/valgrind/valgrind-3.8.1/install/lib/valgrind/vgpreload_massif-amd64-linux.so" --31179-- Reading syms from /home/philippe/valgrind/valgrind-3.8.1/install/lib/valgrind/vgpreload_core-amd64-linux.so --31179-- TOPSPECS of soname NONE filename /home/philippe/valgrind/valgrind-3.8.1/install/lib/valgrind/vgpreload_core-amd64-linux.so --31179-- Reading syms from /home/philippe/valgrind/valgrind-3.8.1/install/lib/valgrind/vgpreload_massif-amd64-linux.so You should then check that the files referenced by initimg exist and have correct permissions (typically -rwxr-xr-x). If initimg is correct and files are existing and have correct permission, then mystery is increasing. You could try the same with memcheck and see if the preload for memcheck is working (and malloc replacement is properly done). You could also verify if the regression test for the static malloc replacement works by doing: cd memcheck/tests/ make static_malloc algrind --tool=massif --soname-synonyms=somalloc=NONE --trace-redir=yes \ -v -v -v -d -d -d ./static_malloc 2>&1 | grep -i preload Philippe |
|
From: Wiser, T. <TW...@lo...> - 2012-11-30 14:56:30
|
>Can you try: >valgrind --tool=massif --soname-synonyms=somalloc=NONE --trace-redir=yes \ > -v -v -v -d -d -d ./MyProg 2>&1 | grep -i preload When I run this command I get the following output: [twiser@twiser-d-01 src]$ ~/programs/valgrind-3.8.1/bin/valgrind --tool=massif --soname-synonyms=somalloc=NONE --trace-redir=yes -v -v -v -d -d -d ./MyProg 2>&1 | grep -i preload --18009:2:initimg preload_string: --18009:2:initimg "/home/twiser/programs/valgrind-3.8.1/lib/valgrind/vgpreload_core-amd64-linux.so:/home/twiser/programs/valgrind-3.8.1/lib/valgrind/vgpreload_massif-amd64-linux.so" >You should then check that the files referenced by initimg exist and have correct permissions (typically -rwxr-xr-x). >If initimg is correct and files are existing and have correct permission, then mystery is increasing. They exist with the proper permissions: [twiser@twiser-d-01 src]$ ll ~/programs/valgrind-3.8.1/lib/valgrind/vgpreload_* -rwxr-xr-x 1 twiser twiser 8800 Nov 26 14:13 /home/twiser/programs/valgrind-3.8.1/lib/valgrind/vgpreload_core-amd64-linux.so -rwxr-xr-x 1 twiser twiser 308233 Nov 26 14:13 /home/twiser/programs/valgrind-3.8.1/lib/valgrind/vgpreload_drd-amd64-linux.so -rwxr-xr-x 1 twiser twiser 64150 Nov 26 14:13 /home/twiser/programs/valgrind-3.8.1/lib/valgrind/vgpreload_exp-dhat-amd64-linux.so -rwxr-xr-x 1 twiser twiser 93564 Nov 26 14:13 /home/twiser/programs/valgrind-3.8.1/lib/valgrind/vgpreload_exp-sgcheck-amd64-linux.so -rwxr-xr-x 1 twiser twiser 175014 Nov 26 14:13 /home/twiser/programs/valgrind-3.8.1/lib/valgrind/vgpreload_helgrind-amd64-linux.so -rwxr-xr-x 1 twiser twiser 64150 Nov 26 14:13 /home/twiser/programs/valgrind-3.8.1/lib/valgrind/vgpreload_massif-amd64-linux.so -rwxr-xr-x 1 twiser twiser 162158 Nov 26 14:13 /home/twiser/programs/valgrind-3.8.1/lib/valgrind/vgpreload_memcheck-amd64-linux.so >You could try the same with memcheck and see if the preload for memcheck is working (and malloc replacement >is properly done). Using memcheck I get the following: [twiser@twiser-d-01 src]$ ~/programs/valgrind-3.8.1/bin/valgrind --tool=memcheck --soname-synonyms=somalloc=NONE --trace-redir=yes -v -v -v -d -d -d ./MyProg 2>&1 | grep -i preload --18018:2:initimg preload_string: --18018:2:initimg "/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" >You could also verify if the regression test for the static malloc replacement works by doing: > cd memcheck/tests/ > make static_malloc > algrind --tool=massif --soname-synonyms=somalloc=NONE --trace-redir=yes \ > -v -v -v -d -d -d ./static_malloc 2>&1 | grep -i preload I ran these with the following results: [twiser@twiser-d-01 tests]$ make static_malloc gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../include -I../../coregrind -I../../include -I../../VEX/pub -DVGA_amd64=1 -DVGO_linux=1 -DVGP_amd64_linux=1 -DVGPV_amd64_linux_vanilla=1 -Winline -Wall -Wshadow -g -m64 -Wno-long-long -Wno-pointer-sign -fno-stack-protector -MT static_malloc.o -MD -MP -MF .deps/static_malloc.Tpo -c -o static_malloc.o static_malloc.c mv -f .deps/static_malloc.Tpo .deps/static_malloc.Po gcc -Winline -Wall -Wshadow -g -m64 -Wno-long-long -Wno-pointer-sign -fno-stack-protector -o static_malloc static_malloc.o [twiser@twiser-d-01 tests]$ ~/programs/valgrind-3.8.1/bin/valgrind --tool=massif --soname-synonyms=somalloc=NONE --trace-redir=yes -v -v -v -d -d -d ./static_malloc 2>&1 | grep -i preload --18058:2:initimg preload_string: --18058:2:initimg "/home/twiser/programs/valgrind-3.8.1/lib/valgrind/vgpreload_core-amd64-linux.so:/home/twiser/programs/valgrind-3.8.1/lib/valgrind/vgpreload_massif-amd64-linux.so" --18058-- Reading syms from /home/twiser/programs/valgrind-3.8.1/lib/valgrind/vgpreload_core-amd64-linux.so --18058-- TOPSPECS of soname NONE filename /home/twiser/programs/valgrind-3.8.1/lib/valgrind/vgpreload_core-amd64-linux.so --18058-- Reading syms from /home/twiser/programs/valgrind-3.8.1/lib/valgrind/vgpreload_massif-amd64-linux.so --18058-- TOPSPECS of soname NONE filename /home/twiser/programs/valgrind-3.8.1/lib/valgrind/vgpreload_massif-amd64-linux.so --18058-- TOPSPECS of soname NONE filename /home/twiser/programs/valgrind-3.8.1/lib/valgrind/vgpreload_core-amd64-linux.so --18058-- TOPSPECS of soname NONE filename /home/twiser/programs/valgrind-3.8.1/lib/valgrind/vgpreload_massif-amd64-linux.so --18058-- TOPSPECS of soname NONE filename /home/twiser/programs/valgrind-3.8.1/lib/valgrind/vgpreload_core-amd64-linux.so --18058:1:aspacem ( 4) /home/twiser/programs/valgrind-3.8.1/lib/valgrind/vgpreload_core-amd64-linux.so --18058:1:aspacem ( 5) /home/twiser/programs/valgrind-3.8.1/lib/valgrind/vgpreload_massif-amd64-linux.so I'm not sure how to interpret these results. Does all this look OK? |
|
From: Philippe W. <phi...@sk...> - 2012-11-30 23:09:42
|
On Fri, 2012-11-30 at 06:56 -0800, Wiser, Tyson wrote: > I'm not sure how to interpret these results. Does all this look OK? Yes, it looks similar to what I see here. To see that the whole replacement thing is working, the command valgrind --tool=memcheck --soname-synonyms=somalloc=NONE ./static_malloc should produce lines telling that the heap was used e.g. ==14445== total heap usage: 2 allocs, 1 frees, 133 bytes allocated ... ==14445== definitely lost: 10 bytes in 1 blocks If the same lines appears in your case, it means the memcheck replacement works on static_malloc. If the replacement is not done (e.g. by using --soname-synonyms=somalloc=FOO), then you rather have ==29278== total heap usage: 0 allocs, 0 frees, 0 bytes allocated With massif correct replacement, it should produce a massif.out.xxxxx file telling some memory was allocated. If that works with the static_malloc program but not with your program, then better file a bug in bugzilla, attaching the full output of -v -v -v -d -d -d --trace-redir=yes. You could also verify that your program is doing a call to malloc (or similar function), find the address of this function A correct redirection for malloc will look like --24545-- REDIR: 0x4004e4 (malloc) redirected to 0x4c25c59 (malloc) (with the malloc "original address" being found by: nm static_malloc | grep malloc 00000000004004e4 T malloc Philippe |
|
From: Wiser, T. <TW...@lo...> - 2012-12-03 16:31:53
|
>To see that the whole replacement thing is working, >the command > valgrind --tool=memcheck --soname-synonyms=somalloc=NONE ./static_malloc > >should produce lines telling that the heap was used e.g. > ==14445== total heap usage: 2 allocs, 1 frees, 133 bytes allocated > ... > ==14445== definitely lost: 10 bytes in 1 blocks > >If the same lines appears in your case, it means the memcheck replacement >works on static_malloc. If the replacement is not done (e.g. >by using --soname-synonyms=somalloc=FOO), then you rather have > ==29278== total heap usage: 0 allocs, 0 frees, 0 bytes allocated > >With massif correct replacement, it should produce a massif.out.xxxxx >file telling some memory was allocated. Both memcheck and massif appear to work correctly with static_malloc. >If that works with the static_malloc program but not with your program, >then better file a bug in bugzilla, attaching the full output >of -v -v -v -d -d -d --trace-redir=yes. I filed bug 311093 with the requested output attached in a tgz file. >You could also verify that your program is doing a call to malloc >(or similar function), find the address of this function >A correct redirection for malloc will look like > --24545-- REDIR: 0x4004e4 (malloc) redirected to 0x4c25c59 (malloc) >(with the malloc "original address" being found by: > nm static_malloc | grep malloc > 00000000004004e4 T malloc The attachment to the bug report also includes the output of running 'nm MyProg | grep malloc' |