On 10.04.2014 21:16, Paul Smith wrote:
> On Thu, 2014-04-10 at 11:15 -0700, John Reiser wrote:
>>> So for example if we have this in MyAlloc.h:
>>>
>>> inline __attribute__((always_inline)) void* MyAlloc(size_t len)
>>> {
>>> return malloc(len);
>>> }
>>>
>>> (obviously our inline function does a bit more than that!), then when I
>>> get a memory loss stacktrace I see something like this:
>>>
>>> ==20930== 18,400 bytes in 23 blocks are possibly lost in loss record 496
>>> of 528
>>> ==20930== at 0x4C2C85E: malloc (vg_replace_malloc.c:292)
>>> ==20930== by 0x6946E0: SparseArray<unsigned int,
>>> 200u>::getPtr(unsigned int)(MyAlloc.h:3)
>>> ==20930== by 0x693250: SparseArray<unsigned int, 200u>::set(unsigned
>>> int, unsigned int) (SparseArray.h:125)
>>> ==20930== by 0x68E5DD: ...
>>>
>>> Note how the function name is correct for the caller of malloc
>>> (getPtr()), BUT the filename/linenumber is for the MyAlloc.h inlined
>>> function rather than where the inlined function was invoked.
>>
>> Please post the traceback that GDB shows.
>
> This is what I get from GDB 7.6.1 (I don't have an example for this same
> stack trace but you can see the format):
>
> #0 malloc (size=24)
> #1 0x0000000000672337 in MyAlloc (size=24) at MyAlloc.h:3
> #2 MsgBody::appendHeader (this=0x7f66d57feb90, cNumber=64) at MsgBody.cpp:101
> #3 0x000000000076b77c in MsgPing::append (this=0x7f66d57feb90,
> val=0x7f66d8c7f700) at MsgPing.cpp:27
> #4 ...
>
> where MsgBody.cpp:101 is an invocation of the MyAlloc() inline function.
> It seems that GDB basically shows two lines at the same instruction
> location, and doesn't prefix the second one with the location.
>
Hi!
Yes, new enough gdb versions know how to display inlined function calls.
I tried to look into this code but did not understand it.
addr2line can also do the same magic.
Until now I solved this by using addr2line. For resolving callstacks
printed by valgrind you need to know the offset between the load address
and the values in the original library (e.g. printed by nm).
This can either be guessed (by comparing the addresses of some functions
in valgrind stacks to what nm prints (regarding offset+size and assuming
the last 3 hex digits stay the same).
That means choosing a short function immediately gives the unambigous
offset.
Additionally I did a patch: Valgrind now writes these load offsets into
the output xml file.
Then I have a postprocessing script that basically subtracts the load
offset of each single address and calls addr2line.
But this is another very slow step (so I only do it on demand).
I can send the patch on monday.
I would be happy if valgrind could do the magic on its own.
Regards
Matthias
------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
