On Sat, 2014-04-12 at 10:56 +0200, Matthias Schwarzott wrote:
> 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 ...
>
> 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.
It would be super-nice if this knowledge were abstracted into a separate
library that was useful and usable by other utilities, such as valgrind.
I don't see why everyone should have to roll their own. Although, I'm
not familiar with how the Valgrind VM works so maybe it's not
sufficiently similar to allow use of the same code as gdb/binutils?
> I can send the patch on monday.
>
> I would be happy if valgrind could do the magic on its own.
Boy, me too! :-).
I don't have the time to learn enough about Valgrind to attempt a fix
myself but I'm willing to test any patches, etc. anyone wants to send
along. And I have enough programming fu to be able to, if not run, then
at least amble with a proposed patch on my own.
------------------------------------------------------------------------------
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
