Gdb dump memory in specific region, save formatted output into a file

Question

I have a buggy (memory leaked) software. As an evidence, I have 1GB of core.dump file. Heap size is 900MB, so obviously, something allocates, but does not free the memory.

So, I have a memory region to examine like this.

(gdb) x/50000s 0x200000000

However, this is hard to guess only with naked eyes, which object or struct is not freed. My idea to trace is, "Save gdb formatted output into a file, and run a pattern match to see which magic string comes up the most." So, here is my question:

How can I save output of following command into a textfile, so that I can write an analyzer?

(gdb) x/10000000s 0x20000000    <-- I need this output into a file

Solution 1

You could use the "dump" function of gdb, see: https://sourceware.org/gdb/onlinedocs/gdb/Dump_002fRestore-Files.html

For your example:

dump binary memory result.bin 0x200000000 0x20000c350

This will give you a plain binary dump int file result.bin. You can also use the following to dump it in hex format:

dump ihex memory result.bin 0x200000000 0x20000c350

Using the dump command is much clearer than using the gdb logging hack (which even did not work for me somehow).

Solution 2

How can I save output of following command into a textfile, so that I can write an analyzer?

 (gdb) x/10000000s 0x20000000

That's actually quite easy:

(gdb) set height 0    # prevent GDB from stopping every screenfull
(gdb) set logging on  # GDB output is now also copied into gdb.txt
(gdb) x/10000000s 0x20000000
(gdb) quit

Voila, enjoy your output in gdb.txt.

I have a buggy (memory leaked) software. ... "Save gdb formatted output into a file, and run a pattern match to see which magic string comes up the most."

That idea is quite unlikely to yield satisfactory results. Consider:

void some_function() {
   std::vector<string> *v = new std::vector<string>();
   // code to insert and use 1000s of strings into "v".
   return;  // Oops: forgot to delete "v".
}

Even if you could effectively "see magic string that comes up the most", you'll discover that you are leaking all the strings; but they are not the problem, leaking "v" is the problem.

So what you really want is to build a graph of which allocated regions point to other allocated regions, and find a "root" of that graph. This is nearly impossible to do by hand.

So what is more likely to help you find the memory leak(s)? Fortunately, there are lots of tools that can solve this problem for you:

• Valgrind,
• Google heap leak checker,
• jemalloc,
• ... etc. etc.

Comments

[Alexander Oh]

There is also a dedicated dump command in gdb. See also: sourceware.org/gdb/onlinedocs/gdb/Dump_002fRestore-Files.htm‌​l

[minmaxavg]

You can just use /dev/kmem or /proc/kcore to do that. Furthurmore, this does not answer the question.