GDB: Listing all mapped memory regions for a crashed process

C Problem Overview

I've got a full-heap core dump from a dead process on an x86 Linux machine (kernel 2.6.35-22 if it matters), which I'm attempting to debug in GDB.

Is there a GDB command I can use that means "show me a list of all the memory address regions allocated by this process?" In other words, can I figure out what all the possible valid memory addresses are that I can examine in this dump?

The reason I ask is that I need to search across the entire process heap for a certain binary string, and in order to use the find command, I need to have a start and end address. Simply searching from 0x00 to 0xff.. doesn't work because find halts as soon as it encounters an address it can't access:

> (gdb) find /w 0x10000000, 0xff000000, > 0x12345678 > > warning: Unable to access target memory at 0x105ef883, halting > search.

So I need to get a list of all the readable address regions in memory so I can search them one at a time.

(The reason I need to do that is I need to find all the structs in memory that point at a certain address.)

None of show mem, show proc, info mem, info proc seem to do what I need.

C Solutions

Solution 1 - C

In GDB 7.2:

(gdb) help info proc
Show /proc process information about any running process.
Specify any process id, or use the program being debugged by default.
Specify any of the following keywords for detailed info:
  mappings -- list of mapped memory regions.
  stat     -- list a bunch of random process info.
  status   -- list a different bunch of random process info.
  all      -- list all available /proc info.

You want info proc mappings, except it doesn't work when there is no /proc (such as during pos-mortem debugging).

Try maintenance info sections instead.

Solution 2 - C

If you have the program and the core file, you can do the following steps.

Run the gdb on the program along with core file

$gdb ./test core
type info files and see what different segments are there in the core file.
```
 (gdb)info files
```

A sample output:

    (gdb)info files 

    Symbols from "/home/emntech/debugging/test".
    Local core dump file:
`/home/emntech/debugging/core', file type elf32-i386.
  0x0055f000 - 0x0055f000 is load1
  0x0057b000 - 0x0057c000 is load2
  0x0057c000 - 0x0057d000 is load3
  0x00746000 - 0x00747000 is load4
  0x00c86000 - 0x00c86000 is load5
  0x00de0000 - 0x00de0000 is load6
  0x00de1000 - 0x00de3000 is load7
  0x00de3000 - 0x00de4000 is load8
  0x00de4000 - 0x00de7000 is load9
  0x08048000 - 0x08048000 is load10
  0x08049000 - 0x0804a000 is load11
  0x0804a000 - 0x0804b000 is load12
  0xb77b9000 - 0xb77ba000 is load13
  0xb77cc000 - 0xb77ce000 is load14
  0xbf91d000 - 0xbf93f000 is load15

In my case I have 15 segments. Each segment has start of the address and end of the address. Choose any segment to search data for. For example lets select load11 and search for a pattern. Load11 has start address 0x08049000 and ends at 0x804a000.

Search for a pattern in the segment.

(gdb) find /w 0x08049000 0x0804a000 0x8048034 0x804903c 0x8049040 2 patterns found

If you don't have executable file you need to use a program which prints data of all segments of a core file. Then you can search for a particular data at an address. I don't find any program as such, you can use the program at the following link which prints data of all segments of a core or an executable file.

 http://emntech.com/programs/printseg.c

Solution 3 - C

(gdb) maintenance info sections 
Exec file:
    `/path/to/app.out', file type elf32-littlearm.
    0x0000->0x0360 at 0x00008000: .intvecs ALLOC LOAD READONLY DATA HAS_CONTENTS

This is from comment by phihag above, deserves a separate answer. This works but info proc does not on the arm-none-eabi-gdb v7.4.1.20130913-cvs from the gcc-arm-none-eabi Ubuntu package.

Solution 4 - C

You can also use info files to list all the sections of all the binaries loaded in process binary.

Solution 5 - C

I have just seen the following:

set mem inaccessible-by-default [on|off]

here

It might allow you to search without regard if the memory is accessible.

Solution 6 - C

The problem with maintenance info sections is that command tries to extract information from the section header of the binary. It does not work if the binary is tripped (e.g by sstrip) or it gives wrong information when the loader may change the memory permission after loading (e.g. the case of RELRO).

Content Type	Original Author	Original Content on Stackoverflow
Question	Crashworks	View Question on Stackoverflow
Solution 1 - C	Employed Russian	View Answer on Stackoverflow
Solution 2 - C	user1203496	View Answer on Stackoverflow
Solution 3 - C	alexei	View Answer on Stackoverflow
Solution 4 - C	abhi	View Answer on Stackoverflow
Solution 5 - C	tothphu	View Answer on Stackoverflow
Solution 6 - C	Ta Thanh Dinh	View Answer on Stackoverflow