Bug 281449 - Addresses of unloaded modules are not translated to functions during "HEAP SUMMARY" report
Summary: Addresses of unloaded modules are not translated to functions during "HEAP SU...
Status: RESOLVED DUPLICATE of bug 79362
Alias: None
Product: valgrind
Classification: Developer tools
Component: memcheck (show other bugs)
Version: 3.6 SVN
Platform: RedHat Enterprise Linux Linux
: NOR minor
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-09-06 06:46 UTC by Zohar Gofer
Modified: 2011-09-06 07:16 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Perl script to fix unknown addresses in HEAP SUMMARY (1.66 KB, application/x-perl)
2011-09-06 06:46 UTC, Zohar Gofer
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Zohar Gofer 2011-09-06 06:46:14 UTC
Created attachment 63428 [details]
Perl script to fix unknown addresses in HEAP SUMMARY

I am using these options:
  --leak-check=full --track-origins=yes -v --log-file=/data/core-valgrind.log

My program is compiled for x86_64 with gcc 4.5.1 and loads many modules dynamically. Error reports during normal operation are fine, but the heap report at the exit is useless, because valgrind fails to translate addresses of unloaded modules to functions.

Example:
==25581== HEAP SUMMARY:
<removed lines>
==25581== 24 bytes in 1 blocks are definitely lost in loss record 15 of 80
==25581==    at 0x4906CF7: operator new(unsigned long) (vg_replace_malloc.c:261)
==25581==    by 0xAB61715: ???
==25581==    by 0xA92B7D6: ???
==25581==    by 0xA92CE17: ???
==25581==    by 0xA92F1BB: ???
==25581==    by 0x8D90E03: ???
==25581==    by 0x8D94C40: ???

I have developed a script based on addr2line to work this problem around. The script is attached.

After running the script, this is what I get:
==25581== HEAP SUMMARY:
<removed lines>
==25581== 24 bytes in 1 blocks are definitely lost in loss record 15 of 80
==25581==    at 0x4906CF7: operator new(unsigned long) (vg_replace_malloc.c:261)
==25581==    by 0xAB61715: ibasicIO::CMgrFileFactory::OpenMgrFile(bool) (Factory.cpp:171)
==25581==    by 0xA92B7D6: irepository::CRepositoryFactory::CRepositoryFactory() (CRepositoryFactory.cpp:83)
==25581==    by 0xA92CE17: irepository::CRepositoryFactory::msCreate() (CRepositoryFactory.cpp:599)
==25581==    by 0xA92F1BB: LoadSubCmpnt (RepositoryMSWIN.cpp:99)
==25581==    by 0x8D90E03: CCmDll::mLoadCmpnt(char const*, void**) (cmDll.cpp:104)
==25581==    by 0x8D94C40: CCmMgr::LoadCmpnt(char const*, void**) (CmpntMgr.cpp:298)

I hope people find this workaround helpful. All the information is there, and this can be done by valgrind instead of externally using addr2line.

Thanks
Comment 1 Tom Hughes 2011-09-06 07:16:29 UTC

*** This bug has been marked as a duplicate of bug 79362 ***