Making calls into the process you are debugging, either by using the call command or by printing expressions that contain calls, has the potential for causing severe non-obvious disruptions. Here are some scenarios to watch out for and how you can extricate yourself from them.
A call might go into an infinite loop, which you can interrupt, or cause a segmentation fault. In many cases you can use a pop -c command to return to the site of the call.
When you make a call in a multi-threaded application, all threads are resumed in order to avoid deadlocks, so you may see side-effects on threads other than the one on which you made the call.
Calls used in breakpoint conditionals might confuse event management (see Resuming Execution.
Some calls made by dbx are performed “safely.” If a problem, typically a segmentation fault, is encountered instead of the usual “Stopped with call to ...”, dbx:
Ignores any stop commands (including those caused by detection of memory access errors)
Automatically issues a pop -c command to return to the site of the call
Proceeds with execution
dbx uses safe calls for:
Calls occurring within an expression printed by the display command. A failed call appears as:ic0->get _data() = <call failed>
To diagnose such a failure, try printing the expression with the print command.
Calls to the db_pretty_print()() function, except when the print -p command is used.
Calls used in event condition expressions. A condition with a failed call evaluates to false.
Calls made to invoke destructors during a pop command.
All internal calls.