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

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

Hi all;  I'm working on GNU/Linux with GCC 4.8.2, binutils 2.23.2, and
Valgrind 1.9.0.  I'm building my code (for this test) with -g and no
optimization.

For various reasons we are using an inlined allocation function that
itself calls malloc().  In order to ensure it works properly for all our
situations (including building as both static and shared libraries: we
don't want to export the inlined function as a weak symbol) we are
marking it with "inline __attribute__((always_inline))".

This is working fine, but there's one issue we've noticed so far: when
Valgrind prints the stack traceback in its output, it's always using the
filename and line number of the _inlined_ function and not the calling
function.  The _name_ of the calling function is correct though.

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.

Any thoughts?