5

I want to print out and analyze the contents of the system heap. Obviously, this should be a privileged operation, and might go against the grain of what GDB was intended to do.

Specifically, I want to scan across the entire systems heap, and not just the processes portion of the heap.

Is this possible with gdb, if so what commands would do it? If not, is there a tool that can do it?

I am willing to set up custom drivers/debug kernal/breakpoints to get this done if necessary.

MrSynAckSter
  • 249
  • You'd need to use a kernel debugger. – teppic Apr 01 '15 at 17:23
  • I figured as much, but the commands and set up for this particular operation are unknown to me. – MrSynAckSter Apr 01 '15 at 17:46
  • 1
    This question seems predicated on the false premise that there is one single "system heap", with "process portions" in multiple processes, in the first place. There is not. Each process has its own heap(s), managed in application memory by its own heap manager(s), layered on top of page-level allocation. You need a clearer idea of what data structure you want to analyze, because the one that you are surmising does not exist. You also need to state which operating system kernel you want to analyze. They are far from all the same, internally; nor are their tools the same. – JdeBP Apr 01 '15 at 19:20
  • Let us assume Linux, and that I want to iterate over each process heap. I assume that all process heaps are handled by a centralized heap manager. Obviously each heap is kept separate as a data structure, but I am assuming that they can be collectively queried somehow. – MrSynAckSter Apr 01 '15 at 19:22
  • Maybe the search command in the crash utility? – Mark Plotnick Jun 06 '20 at 11:14

1 Answers1

8

First you need to understand the basics of virtual memory. You don't need to understand how a MMU works, but you do need to understand what a virtual address space is, and when you're dealing with virtual addresses or physical addresses. Otherwise you won't be able to make any sense of what you see.

Under Linux, you can access the system's physical memory via /dev/mem: byte N of /dev/mem is byte N in RAM or in memory-mapped peripherals. Unless you already know what you're looking for and where to look it for, you'll have a hard time finding interesting things there. The file /proc/iomem describes what is mapped in the physical address space (RAM and peripherals).

You can access the kernel's virtual memory via /dev/kmem: that gives you access to kernel code and data structures, and to devices that are currently mapped in the kernel, but not to process memory. Linux also has /proc/kcore, which is similar to /dev/kmem but puts an ELF header at the beginning, to facilitate running a debugger on the kernel. A debugger can open /proc/kcore and work on it much like it would work on a process's memory. You can debug a running kernel by running gdb /path/to/vmlinux /proc/kcore (there are more convenient facilities, in particular for remote debugging).

You can access a process's virtual memory via /proc/$PID/mem. The file /proc/$PID/maps summarizes what is mapped in the process's address space; /proc/$PID/smaps goes into more detail.

There is no such thing as a “system heap” or a “centralized heap manager”. The closest thing is the whole system memory and the memory manager (all ~100kLoC of it in Linux, not including architecture-specific parts).

Community
  • 1
Gilles 'SO- stop being evil'
  • 829,060