Re: [Valgrind-users] Wrong function names (or line numbers) in ms_print output

[Philippe W. <phi...@sk...>]

On Wed, 2015-12-09 at 13:41 -0800, Nikolaus Rath wrote:
> I believe this is the relevant objdump output - but again I don't understand it. Does it tell you anything?
> 
>  <1><a8f8c>: Abbrev Number: 42 (DW_TAG_subprogram)
>     <a8f8d>   DW_AT_decl_line   : 1916
>     <a8f8f>   DW_AT_decl_file   : 1
>     <a8f90>   DW_AT_declaration : 1
>     <a8f91>   DW_AT_name        : (indirect string, offset: 0xa5fc): h5dump_attr_int
>     <a8f95>   DW_AT_external    : 1
>     <a8f96>   DW_AT_inline      : 1     (inlined)

So, we have now clearly confirmed that the wrong stacktrace is caused by
valgrind not understanding that h5dump_attr_int has been inlined.

What you could do is to modify storage.c line 668 put a (1) instead of
(0) :

    if (0) VG_(message)
             (Vg_DebugMsg, 
              "addInlInfo: fn %s inlined as addr_lo %#lx,addr_hi %#lx,"
              "caller fndn_ix %u %s:%d\n",
              inlinedfn, addr_lo, addr_hi, fndn_ix,
              ML_(fndn_ix2filename) (di, fndn_ix), lineno);


This will then trace the inlined call information.
If this inlined info is properly understood and recorded, you should
see some information produced that tells that h5dump_attr_int
has been inlined around the program counter of:
==2047==    by 0xB99FC6: taehdf5_mp_h5append_data_double_0d_ (taehdf5.f90:1936)

If this is not recorded, then it is the valgrind dwarf reader that likely has
a problem.
Otherwise, it is the unwinder which does not properly use the inline info.

Philippe