While dbx provides you with a rich set of breakpoint types through the event mechanism, it also uses many events internally. By stopping on some of these internal events you can easily disrupt the internal workings of dbx. If you modify the process state in these cases the chance of disruption is even higher. See Modifying a Program State and Call Safety.
dbx can protect itself from disruption in some cases but not all cases. Some events are implemented in terms of lower level events. For example, all stepping is based on the fault FLTTRACE event. So, issuing the command stop fault FLTTRACE disrupts stepping.
During the following phases of debugging, dbx is unable to handle user events because they interfere with some careful internal orchestration. These phases include:
When rtld runs at program startup (see Dynamic Linker)
The beginning and end of processes
Following the fork() function and the exec() function (see Following the fork Function and Following the exec Function
During calls when dbx needs to initialize a head in the user process (proc_heap_init())
During calls when dbx needs to ensure availability of mapped pages on the stack (ensure_stack_memory())
In many cases you can use the when command instead of the stop command, and echo the information you would have otherwise acquired interactively.
dbx protects itself by:
Disallowing the stop command for the sync, syncrtld, and prog_new events
Ignoring the stop command during the rtld handshake and the other phases mentioned above
For example:
...SolBook linebreakstopped in munmap at 0xff3d503c 0xff3d503c: munmap+0x0004: ta %icc,0x00000008SolBook linebreak dbx76: warning: 'stop' ignored -- while doing rtld handshake
Only the stoppage effect, including recording in the $firedhandlers variable, is ignored. Counts or filters are still active. To stop in such a case, set the event_safety environment variable to off.