|
From: Praveen <pra...@ya...> - 2007-10-25 20:51:45
|
Hi all, Im trying to run valgrind on a piece of code which makes function calls from within a macro expansion. And the trace looks like this: ==6117== 8,588 (3,568 direct, 5,020 indirect) bytes in 5 blocks are definitely lost in loss record 4 of 6 ==6117== at 0x401D7AA: calloc (vg_replace_malloc.c:279) ==6117== by 0x4495FC9: ??? ==6117== by 0x44A3CDF: ??? ==6117== by 0x44A4C1E: ??? ==6117== by 0x4482E62: ??? ==6117== by 0x4415696: ??? ==6117== by 0x80601FC: plugins_call_init (plugin.c:407) ==6117== by 0x804DE11: main (server.c:867) What is the cause for the above output? How do I get the complete trace (with function names instead of ???)? Thanks, Praveen __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
|
From: Igmar P. <mai...@jd...> - 2007-10-26 08:30:44
|
> ==6117== by 0x4415696: ??? > > ==6117== by 0x80601FC: plugins_call_init (plugin.c:407) > > ==6117== by 0x804DE11: main (server.c:867) > > What is the cause for the above output? How do I get the complete trace (with function names instead of ???)? compile the shared object you're loading / linking agains with debugging support. Igmar |
|
From: Tom H. <to...@co...> - 2007-10-26 08:54:00
|
In message <Pin...@jd...>
Igmar Palsenberg <mai...@jd...> wrote:
>> ==6117== by 0x4415696: ???
>> ==6117== by 0x80601FC: plugins_call_init (plugin.c:407)
>> ==6117== by 0x804DE11: main (server.c:867)
>>
>> What is the cause for the above output? How do I get the complete trace (with function names instead of ???)?
>
> compile the shared object you're loading / linking agains with debugging
> support.
Given the fact that stack is below plugins_call_init I'd guess that
the code in question is in a plugin that has been unloaded with
dlclose before the leak checker runs and that is why valgrind is
not able to see any symbols for it.
The easiest fix is probable to tweak the code to not unload the
plugins so that you can see where the leak is.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|