> 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. This
> example happens to C++ templates but the same thing happens for
> straightforward function calls.
>
> This is very painful because that function might allocate memory in many
> different places and I have no idea which one valgrind is talking about.
>
> If use GDB and set a breakpoint on malloc, then the stacktrace shown by
> GDB is correct: it shows a separate stack frame for the inlined
> allocation function and then the "right" stack frame for the caller.
Please post the traceback that GDB shows. You have done an excellent job
at presenting your environment (thank you for the software versions!)
and the actual output that you see from memcheck. However I'm unsure
of exactly the output that you desire.
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.
------------------------------------------------------------------------------
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
