Re: [Valgrind-users] Stack trace missing frame with inlined allocation function?

[Paul S. <pa...@ma...>]

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.

> If you want
>  ==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: MyAlloc (MyAlloc.h:3)
>  ==20930==    by 0x6946E0: SparseArray<unsigned int, 200u>::getPtr(unsigned int) (SparseArray.h:234)
>  ==20930==    by 0x693250: SparseArray<unsigned int, 200u>::set(unsigned int, unsigned int) (SparseArray.h:125)
>  ==20930==    by 0x68E5DD: ...
> then there may be a problem with having the same return address for MyAlloc.h:3 and SparseArray.h:234
> when only one actual subroutine CALL instruction is involved.

If I could only get one frame and I had to choose whether I got the
filename/linenumber info from the caller or the inline function, I would
choose the caller, myself.

In my situation the inline function is small and calls malloc() exactly
once so I can easily infer what happens and if I didn't have that info I
would probably not even notice.  But, I can imagine other situations
where the inline function was more complex and contained multiple
invocations of malloc itself, then not having the inline
filename/linenumber as well could be a bummer.

But I still think, overall, the caller is more helpful most of the
time :-).


Cheers!