If you set a breakpoint with a filter that contains function calls in a multithreaded program, dbx stops execution of all threads when it hits the breakpoint and then evaluates the condition. If the condition is met and the function is called, dbx resumes all threads for the duration of the call.
For example, you might set the following breakpoint in a multithreaded application where many threads call lookup():
(dbx) stop in lookup -if strcmp(name, “troublesome”) == 0
dbx stops when thread t@1 calls lookup(), evaluates the condition, and calls strcmp() resuming all threads. If dbx hits the breakpoint in another thread during the function call, it issues a warning such as one of the following:
event infinite loop causes missed events in the following handlers: ...
Event reentrancy first event BPT(VID 6m TID 6, PC echo+0x8) second event BPT*VID 10, TID 10, PC echo+0x8) the following handlers will miss events: ...
In such a case, if you can ascertain that the function called in the conditional expression will not grab a mutex, you can use the -resumeone event specification modifier to force dbx to resume only the first thread in which it hit the breakpoint. For example, you might set the following breakpoint:
(dbx) stop in lookup -resumeone -if strcmp(name, “troublesome”) == 0
The -resumeone modifier does not prevent problems in all cases. For example, it would not help in the following circumstances:
The second breakpoint on lookup() occurs in the same thread as the first because the condition recursively calls lookup().
The thread on which the condition runs relinquishes control to another thread.
For detailed information, see Event Specification Modifiers.