0

I would like to capture what is, in effect, a heap dump at procedure call time in a C (or C++) program. However, I am interested in what is heap-reachable from global variables and arguments.

This might be done by using some gdb command that dumps memory - is there a way to restrict that to the heap that is reachable from the entry points above? If not, is it possible to dump core and then reverse engineer the reachable part, or is there a fundamental reason why not?

Another angle might be to run the program under an emulator like valgrind. But as far as I know, only statistics can be captured this way, not actual heap contents.

Yet another possibility might be to patch/abuse a library like dmalloc or electric fence. Would this be remotely workable?

Full debug information can be safely assumed, as well as access to the source code, e.g., for instrumentation purposes.

Nikos
  • 219
  • 1
  • 8
  • You might want to look at the first answer here: http://stackoverflow.com/questions/24280361/detect-c-memory-leaks-that-are-freed-on-exit – abligh Mar 30 '15 at 17:22
  • Thanks. Without having tried `memcheck` my understanding is that the answer you point out is specifically about memory leaks and that it does not provide a full description of the heap state. Have I missed something? – Nikos Mar 30 '15 at 17:37
  • it's not *quite* a match for what you are asking, but the 'leaks' I ask about are in fact leaks only during the duration of the program - i.e. stuff on the heap which is freed at the end. It's sort of equivalent to pressing `^C` on the program when running under `valgrind`, which tells you what leaked if the program exited then. That's broadly equivalent to the state of the heap. I was more meaning the `vgdb` way in any case. – abligh Mar 30 '15 at 17:39

0 Answers0