36

I am debugging a program in gdb and I want the program to stop when the memory region 0x08049000 to 0x0804a000 is accessed. When I try to set memory breakpoints manually, gdb does not seem to support more than two locations at a time.

(gdb) awatch *0x08049000
Hardware access (read/write) watchpoint 1: *0x08049000
(gdb) awatch *0x08049001
Hardware access (read/write) watchpoint 2: *0x08049001
(gdb) awatch *0x08049002
Hardware access (read/write) watchpoint 3: *0x08049002
(gdb) run
Starting program: /home/iblue/git/some-code/some-executable
Warning:
Could not insert hardware watchpoint 3.
Could not insert hardware breakpoints:
You may have requested too many hardware breakpoints/watchpoints.

There is already a question where this has been asked and the answer was, that it may be possible to do this with valgrind. Unfortunately the answer does not contain any examples or reference to the valgrind manual, so it was not very enlightning: How can gdb be used to watch for any changes in an entire region of memory?

So: How can I watch the whole memory region?

Community
  • 1
  • 1
iblue
  • 29,609
  • 19
  • 89
  • 128

3 Answers3

32

If you use GDB 7.4 together with Valgrind 3.7.0, then you have unlimited "emulated" hardware watchpoints.

Start your program under Valgrind, giving the arguments --vgdb=full --vgdb-error=0 then use GDB to connect to it (target remote | vgdb). Then you can e.g. watch or awatch or rwatch a memory range by doing rwatch (char[100]) *0x5180040

See the Valgrind user manual on gdb integration for more details

iblue
  • 29,609
  • 19
  • 89
  • 128
phd
  • 556
  • 3
  • 3
  • 4
    After I spent the better part of the day fiddling with `mprotect` and abusing SIGSEV handlers to break on memory access, I tried this. It works perfectly. You saved my day. Thank you! – iblue Jun 13 '12 at 23:00
  • Yes, +1 also. I've been hunting for a feature like this for months. – Crashworks Jun 14 '12 at 00:10
  • So, how does one determine the heap address for the process started by valgrind? I usually do this via */proc/[pid]/maps* but when I start python via this valgrind command, the maps file doesn't have an entry identified by **[heap]** as I'm used to finding. – Andrew Falanga Feb 11 '16 at 19:59
  • 1
    I realise that this answer was written a long time ago, but I am confused by this answer, because gdb can do that by itself, without valgrind's help. At least it can now. It will resort to single-step and check repeatedly. That's obviously really expensive (like valgrind is), so you would narrow it down to when the corruption is about to happen soon, then create the watchpoint, so you don't have it running slow the whole debug run. – doug65536 Dec 10 '20 at 03:40
16

The feature that detects when a memory address has changed is called a hardware breakpoint, and it's actually a feature of the CPU — a register inside the memory controller that detects when a specific address is accessed, and triggers a debugger break interrupt. Unfortunately the x86 architecture only has four such registers and that's why you're limited in the number of memory watch breakpoints you can set.

That's why you need to use something like valgrind; if you want to watch an entire region, you have to do it by using software that simulates the memory access patterns. I don't know if valgrind actually supports watching entire memory ranges, though. You may have to patch it yourself. Modify VALGRIND_MAKE_MEM_NOACCESS() to throw a breakpoint but then allow the program to continue, maybe.

Crashworks
  • 40,496
  • 12
  • 101
  • 170
1

I have verified that recent gdb itself does support watching a range of addresses now, then Valgrind is not a must as other answers suggested, test env:

  • GNU gdb (Ubuntu 12.1-0ubuntu1~22.04) 12.1
  • 11th Gen Intel(R) Core(TM) i7-11800H @ 2.30GHz

With the command:

watch *(char [100]*)&gbuf

Then we start to watch the address range [gbuf, gbuf + 100)

prehistoricpenguin
  • 6,130
  • 3
  • 25
  • 42