On 12/08/2015 02:26 PM, Philippe Waroquiers wrote: > On Tue, 2015-12-08 at 09:08 -0800, Nikolaus Rath wrote: >> Hello, >> >> I'm having a problem using massif. When looking at the ms_print output, I'm >> getting entries like this: >> >> ->10.77% (11,146,544B) 0xF4AC9C: H5FL_reg_calloc (in >> /work/nrath/issue_2014_q2d_mem/part_agmg0_4_massif_fixed/LR_model) >> | ->10.58% (10,946,896B) 0x1000D57: H5S_copy (in >> /work/nrath/issue_2014_q2d_mem/part_agmg0_4_massif_fixed/LR_model) >> | | ->10.57% (10,940,640B) 0xEE0A80: H5A_create (in >> /work/nrath/issue_2014_q2d_mem/part_agmg0_4_massif_fixed/LR_model) >> | | | ->10.57% (10,940,640B) 0xEDAAAF: H5Acreate2 (in >> /work/nrath/issue_2014_q2d_mem/part_agmg0_4_massif_fixed/LR_model) >> | | | ->10.57% (10,940,640B) 0xEC985C: h5acreate_c_ (in >> /work/nrath/issue_2014_q2d_mem/part_agmg0_4_massif_fixed/LR_model) >> | | | ->10.57% (10,940,640B) 0xEC3C55: h5a_mp_h5acreate_f_ (in >> /work/nrath/issue_2014_q2d_mem/part_agmg0_4_massif_fixed/LR_model) >> | | | ->10.57% (10,940,640B) 0xB99ED5: >> taehdf5_mp_h5append_data_double_0d_ (taehdf5.f90:1936) >> | | | ->04.24% (4,387,296B) in 40 places, all below massif's >> threshold (01.00%) >> >> >> However, line 1936 of taehdf5.f90 is actually inside a different subroutine, >> defined as: >> >> subroutine h5dump_attr_int(loc_id,f,name) >> [..] >> ! next line is 1936 >> call h5acreate_f(loc_id,name,H5T_NATIVE_INTEGER,space_id,attr_id,hdferr) >> [...] >> end subroutine >> >> >> The h5append_data_double_0d subroutine is actually defined much later, >> starting in line 4120 with: >> >> subroutine h5append_data_double_0d(group_id,f,name) >> >> ..and it does not contain any calls to h5acreate_f. So I think that probably >> the line number is correct, but the function name is not. >> >> Does anyone know what might cause this? > > What is the platform ? (version of valgrind/os/gcc, which cpu, ....) ?
$ uname -a Linux ibm-h1.localcluster 2.6.32-431.el6.x86_64 #1 SMP Sun Nov 10 22:19:54 EST 2013 x86_64 x86_64 x86_64 GNU/Linux $ cat /proc/cpuinfo | head -10 processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 62 model name : Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz stepping : 4 cpu MHz : 1200.000 cache size : 20480 KB physical id : 0 siblings : 8 $ valgrind --version valgrind-3.8.1 The binary I'm analyzing has been compiled with $ ifort --version ifort (IFORT) 15.0.0 20140723 Copyright (C) 1985-2014 Intel Corporation. All rights reserved. > Strange stacktraces can be given in case the compiler is inlining some > calls or if Valgrind unwinder has a bug. Inlining was what came to my mind at first too. But in my experience this only causes a difference of a few lines - not more than 2000. > You might check that using gdb+vgdb: put a break on H5FL_reg_calloc. > When break encountered, do > (gdb) backtrace Hmm. This is interesting. If I ask gcc for a backtrace, it just hangs: (gdb) b H5FL_reg_calloc Breakpoint 4 at 0xf4abf0 (gdb) c Continuing. Breakpoint 4, 0x0000000000f4abf0 in H5FL_reg_calloc () (gdb) backtrace #0 0x0000000000f4abf0 in H5FL_reg_calloc () #1 0x0000000000fada52 in H5O_attr_shared_decode () #2 0x0000000000fd0f7c in H5O_msg_iterate_real () #3 0x0000000000fb411b in H5O_attr_exists () #4 0x0000000000ee08ab in H5A_create () #5 0x0000000000edaab1 in H5Acreate2 () #6 0x0000000000ec985e in h5acreate_c_ () #7 0x0000000000ec3c57 in h5a_mp_h5acreate_f_ () #8 0x0000000000ba1ec8 in h5dump_attr_double (loc_id=1, After pressing Ctrl-C: #8 0x0000000000ba1ec8 in h5dump_attr_double (loc_id=1, ^C f=<error reading variable: Cannot access memory at address 0xa000008>, name=Quit Might this have something to do with the problem? That said, I don't think the above backtrace is the right one, because H5FL_reg_calloc is called via a ton of different code paths. Is there a way to break in this function only when entered via the codepath that valgrind gave above? Thanks for your help, -Nikolaus ------------------------------------------------------------------------------ _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
