Since the core file
created when the process die for any reason contains the content of the memory at that moment I suppose is possible to use gdb
to perform some checks on the memory, but I have no idea how to use gdb
for this.
Regards
When glibc
debuginfo is installed (e.g. on Fedora 22: dnf debuginfo-install glibc-2.21-5.fc22.x86_64
) one can print out the main_arena
and mp_
.
The output for a core dump of a program which malloced one time 1000 bytes and one time 200000 bytes is as follows:
(gdb) p main_arena.system_mem
$3 = 135168
(gdb) p main_arena.max_system_mem
$4 = 135168
(gdb) p mp_
$5 = {trim_threshold = 131072, top_pad = 131072, mmap_threshold = 131072, arena_test = 8, arena_max = 0, n_mmaps = 1,
n_mmaps_max = 65536, max_n_mmaps = 1, no_dyn_threshold = 0, mmapped_mem = 200704, max_mmapped_mem = 200704,
max_total_mem = 0, sbrk_base = 0x1ace000 ""}
(gdb)
That means that total heap size is 135168 bytes including the free memory chunks. This is also the maximum ever reached value. Memory mapped memory is 200704 bytes, 200000 bytes rounded up to 196 kB.
You can see some information about the heap using info proc mappings
.
Finding the number of instances of a given class is trickier. By itself, gdb doesn't know anything about the heap layout of your application. You are left to explore it on your own.
However, there are some tools to help. A good place to start is the gdb-heap project, which teaches gdb about how glibc manages the heap. From this could you find allocations and examine vtable pointers to find instances of objects -- at least objects that have vtables. I don't think there is any generic way to find instances of other kinds of objects.
gdb-heap may need some hacking to be usable for your purposes.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With