On Tue, 2015-12-08 at 14:39 -0800, Nikolaus Rath wrote: > $ valgrind --version > valgrind-3.8.1 This is more than 3 years old. Would be (much) better to upgrade to the last version (3.11). In any case, if the problem is related to inlining, you need a recent valgrind version to see it (inlining info was implemented in 3.10).
> 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. The difference will only depend on where the inlining and inlined functions are, and these do not need to be close to each other. > Hmm. This is interesting. If I ask gcc for a backtrace, it just hangs: ... > 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? Maybe : it is possible that ifort generates unusual code/debug info, that gdb and/or valgrind unwinder do not understand. You might also maybe upgrade gdb (if you are using an old gdb version). > > > 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? No (easy) way that I know. So, you will have to put a break in the function that is most likely to be called only in the interesting stacktrace, and then put a break on H5FL_reg_calloc and continue. Philippe ------------------------------------------------------------------------------ _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
