20

Do you know any other reasons why a watchpoint could not be inserted other than too many hardware breakpoints/watchpoints?

I have the following debug session:

GNU gdb (GDB) 7.1
...
(gdb) watch itrap_t_beg[1][222]
Hardware watchpoint 1: itrap_t_beg[1][222]
(gdb) cont
Continuing.
...
Hardware watchpoint 1: itrap_t_beg[1][222]

...
(gdb) cont
Continuing.
Warning:
Could not insert hardware watchpoint 1.
Could not insert hardware breakpoints:
You may have requested too many hardware breakpoints/watchpoints.

(gdb) info break
Num     Type           Disp Enb Address            What
1       hw watchpoint  keep y                      itrap_t_beg[1][222]
        breakpoint already hit 1 time

As you can see, there's only one watchpoint yet it can't insert the breakpoint.

Do you know how can I fix this?

Gaston
  • 1,828
  • 2
  • 15
  • 29

3 Answers3

18

As far as I know commodity x86 CPUs have four debug registers available for supporting hardware breaks/watches. This limits the object size that you can watch. Object alignment also plays here.

Try limiting the watch scope to a smaller object like pair of first and last members of the structure.

Nikolai Fetissov
  • 82,306
  • 11
  • 110
  • 171
  • 1
    Hey! It worked! Thanks. The strange thing is that I could set the first watch. Maybe, at that point, the itrap_t_beg was a char* and then it was casted to trap* (the source code is very old and things like that can happen). Thanks again! – Gaston Jul 08 '10 at 19:14
14

Can force software breakpoints (which do not have limit on size) by running

set can-use-hw-watchpoints 0

Wrikken
  • 69,272
  • 8
  • 97
  • 136
Akhil
  • 2,269
  • 6
  • 32
  • 39
9

Shot answer: Use watch -location itrap_t_beg[1][222], or the short form watch -l.

Long answer: Quoting the GDB manual:

Watching complex expressions that reference many variables can also exhaust the resources available for hardware-assisted watchpoints. That's because gdb needs to watch every variable in the expression with separately allocated resources.

gdb quite literally watches the expression itself, not whatever address it points to. In this case, it means that the breakpoint will hit if itrap_t_beg itself is changed such that itrap_t_beg[1][222] does; there's not just a watchpoint for itrap_t_beg[1][222], but also one for itrap_t_beg itself. This may be more than what's available.

In your case, itrap_t_beg is 7 ints, 28 bytes. A x86_64 watchpoint is up to eight bytes, so GDB needs four watchpoints for the entire structure - plus a fifth for itrap_t_beg itself. The x86 family only supports four simultaneous watchpoints.

A more comprehensive example on how watchpoints work:

//set a watchpoint on '*p' before running
#include <stdio.h>
int a = 0;
int b = 0;
int c = 0;
int* p = &a;

int main()
{
    puts("Hi"); // Dummy lines to make the results clearer, watchpoints stop at the line after the change
    *p = 1; // Breaks: *p was changed from 0 to 1
    puts("Hi");
    a = 2; // Breaks: a is *p, which changed from 1 to 2
    puts("Hi");
    p = &b; // Breaks: p is now b, changing *p from 2 to 0
    puts("Hi");
    p = &c; // Doesn't break: while p changed, *p is still 0
    puts("Hi");
    p = NULL; // Breaks: *p is now unreadable
    puts("Hi");
    return 0;
}

In theory, this is a useful feature; you can watch a complex expression, breaking as soon as it's false, somewhat like a constantly-tested assertion. For example, you can watch a==b in the above program.

In practice, it's unexpected, often triggers this issue, and usually isn't what you want.

To watch only the target address, use watch -location itrap_t_beg[1][222]. (This is available as of GDB 7.3, released in July 2011; if you're still on 7.1, use print &itrap_t_beg[1][222] and watch *(itrap_t)0x12345678, or whichever address it prints.)

Alcaro
  • 1,664
  • 16
  • 21
  • 2
    This answer is mostly cross-posted from [this question](http://stackoverflow.com/questions/3206332/gdb-stops-with-too-many-watchpoints-when-there-is-only-one), since this is the top Google hit for "You may have requested too many hardware breakpoints/watchpoints." – Alcaro Feb 15 '17 at 13:49
  • 1
    Please don't add the same answer to multiple questions. Answer the best one and flag the rest as duplicates. See [Is it acceptable to add a duplicate answer to several questions?](http://meta.stackexchange.com/questions/104227/is-it-acceptable-to-add-a-duplica‌​te-answer-to-several-questions) – Petter Friberg Feb 15 '17 at 13:52