Oracle® Solaris Studio 12.4: Debugging a Program With dbx

Exit Print View

Updated: January 2015
 
 

Resuming Execution

Use the cont command to resume program execution. Currently, threads use synchronous breakpoints, so all threads resume execution. However, you can resume a single thread using the call command with the –resumeone option.

    Consider the following two scenarios when debugging a multithreaded application where many threads call the function lookup():

  • You set a conditional breakpoint:

    stop in lookup -if strcmp(name, "troublesome") == 0

    When t@1 stops at the call to lookup(), dbx attempts to evaluate the condition and calls strcmp().

  • You set a breakpoint:

    stop in lookup

    When t@1 stops at the call to lookup(), you issue the command:

    call strcmp(name, "troublesome")

When calling strcmp(), dbx would resume all threads for the duration of the call, which is similar to what dbx does when you are single-stepping with the next command. It does so because resuming only t@1 has the potential to cause a deadlock if strcmp() tries to grab a lock that is owned by another thread.

A drawback to resuming all threads in this case is that dbx cannot handle another thread, such as t@2, hitting the breakpoint at lookup() whilestrcmp() is being called. It emits a warning like one of the following:

event infinite loop causes missed events in following handlers:

Event reentrancy first event BPT(VID 6, TID 6, PC echo+0x8) second event BPT(VID 10, TID 10, PC echo+0x8) the following handlers will miss events:

In such cases, if you can ascertain that the function called in the conditional expression will not grab a mutex, you can use the -resumeone event modifier to force dbx to resume only t@1:

stop in lookup -resumeone -if strcmp(name, "troublesome") == 0

Only the thread that hit the breakpoint in lookup() would be resumed in order to evaluate strcmp().

    This approach does not help in cases such as the following examples:

  • If the second breakpoint on lookup() happens in the same thread because the conditional recursively calls lookup()

  • If the thread on which the conditional runs yields, sleeps, or in some manner relinquishes control to another thread