a conditional breakpoint
A plain breakpoint on a line inside a loop is annoying when the loop runs a million times and the bug only happens on iteration 743,219. Stopping a million times and clicking 'continue' is hopeless. A conditional breakpoint fixes this: it is a normal breakpoint with a yes/no test attached, and it only actually stops the program when that test is true. The program keeps flying past the line every other time and pauses only on the moment you care about.
Concretely, you set a breakpoint and give it a condition written in terms of your program's variables. In gdb: 'break process.c:88 if id == 743219', or you set a breakpoint first and then attach 'condition 1 errno != 0'. Each time the line is reached, the debugger silently evaluates the expression; if it is false the program continues as if nothing happened, and if it is true the program stops and hands you control. The cost is real but usually worth it: the debugger has to pause invisibly and check the condition on every pass, which is slower than a bare breakpoint, but far faster than you stopping manually each time.
Why it matters: conditional breakpoints let you jump straight to the interesting case - the one bad input, the one NULL pointer, the one iteration where a counter goes wrong - without manually stepping through thousands of healthy ones. A close cousin is an ignore count ('skip this breakpoint 50 times, then stop'), useful when you know roughly which pass fails. Use them when you can describe the bad state as a simple expression; if you cannot yet describe it, a watchpoint on the suspect data, or plain stepping, may get you there first.
In gdb: break handle_item if item == NULL means 'stop inside handle_item only on the call where item is a null pointer'. The loop runs full speed over all the valid items and freezes exactly on the bad one, so the backtrace points straight at the caller that passed NULL.
Stop only when item == NULL, skipping every healthy iteration.
The condition is evaluated by the debugger on every hit, so a conditional breakpoint inside a hot loop can slow the run noticeably; if it is too slow, a watchpoint or restructuring the test may be faster. Beware that the condition can only use names in scope at that line.