Call Safety

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.