Oracle® Solaris Studio 12.4: Debugging a Program With dbx

Exit Print View

Updated: January 2015
 
 

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. For example:

  • 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 multithreaded application, all threads are resumed in order to avoid deadlocks, so you might 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 does one of the following actions:

  • 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 the following situations:

  • 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.