Debugging Multi-Threaded Applications

Making libdce.sl Writable

If your application uses /usr/lib/libdce.sl (the shared library version of HP DCE threads), you must make the shared library writable before you debug the application.

The following command maps all shared libraries as writable:

property flags tgt_shlib_debug

You can place the command in your .dderc file. You can also invoke it from the debugger command line before you issue the debug command.

When libdce.sl is read-only, you cannot step into routines or set breakpoints in them. Also, some thread-related debugger commands will not work. The affected commands are:

intercept thread_create
intercept thread_exit
intercept thread_switch
thread

If libdce.sl is read-only and you attempt to use one of the commands listed above, the debugger will display a not mapped writable message.

Stripped and Unstripped Versions of libdce.sl

If your application links in an unstripped version of /usr/lib/libdce.sl, all threads-related commands and options will work properly.

If, however, your program links in a stripped version of /usr/lib/libdce.sl, the threads-related commands and options will behave as if your program had only one thread.

Use the nm command to determine if your system has a stripped version of libdce.sl. The output of nm contains a no symbols message when libdce.sl is stripped. For example:

$ nm /usr/lib/libdce.sl nm: /usr/lib/libdce.sl: no symbols

If libdce.sl is stripped, link your program with the archive library /usr/lib/libdce.a in order to debug it.

Viewing and Manipulating Threads

Choose Execution:Threads to display the Threads dialog box. The Threads dialog box, shown in Figure 8-1 “The Threads Dialog Box ”, displays a list of threads in your program. The list is automatically updated as threads are created or change status.

Figure 8-1 The Threads Dialog Box

Notice the following in the thread list:

You can also use the list threads command to display a list similar to the one in the Threads dialog box.

When you highlight one or more threads in the Threads dialog box, you can select a button to request the following actions:

Setting Breakpoints on Threads

You can activate breakpoints on all threads, or on any selected set of threads.

The Breakpoints Set/Change dialog box contains an area at the bottom which allows you select which threads the breakpoint will be set on. Choose Break:Set to invoke the Breakpoints Set/Change dialog box.

Also, the breakpoint command has a -thread option. See the online command reference for more information and examples.

Environment in Multi-Threaded Applications

When the target program is multi-threaded, the debugger includes a thread component in its concept of environment. (See Chapter 7 “Identifying Program Objects ” for more information on the debugger's general concept of environment.)

For example, the following shows the output from a list environment command during a debugging session on a multi-threaded target program:

list environment
Stopped at: \\file_copy\worker\222 (`thread(3))

Notice the output indicates that the current environment is in Thread 3.

It is useful to invoke the Stack View dialog box when debugging multi-threaded programs. You can invoke it by selecting Show:Stack from the menu bar.

Figure 8-2 Stack View Dialog Box Showing Current Thread

As shown in Figure 8-2 “Stack View Dialog Box Showing Current Thread ”, the Stack View dialog box shows the call/return stack for the current thread. The current thread is the thread that the debugger refers to when evaluating expressions. It differs from the running thread when you change environment from one thread to another. For example, you can use the thread specifier, `thread(n) to change the current thread, in the following context:

environment `thread(3)

Notice that the call/return stack in multi-threaded applications includes a number of system calls. In Figure 8-2 “Stack View Dialog Box Showing Current Thread ”, the system call names begin with the cma__ prefix.

Arrow buttons in the Stack View dialog box allow you to move up and down the call/return stack within the current thread. You can also use the frame specifiers described in Chapter 7 “Identifying Program Objects ” (`env, `run, and `main). The command environment `env(-1), for example, moves to the caller of the current frame without changing the current thread.

In addition, you can combine thread specifiers with frame specifiers to write fully qualified environment specifiers. The following shows the syntax for fully qualified environment specifiers:

`thread(thread_id)\`main(frame_number)
`thread(thread_id)\`run(frame_number)
`thread(thread_id)\`env(+|-n)

The `thread(thread_id) notation may also be used wherever another environment qualifier can be used. The command print `thread(5)\x, for example, prints the variable x in the environment of the run frame of Thread 5.

Thread-Specific Debugger Commands

The two commands that apply specifically to debugging threaded applications are list threads and thread.

Use the list threads command to obtain a list of thread identifiers for a target program. You can also use the Threads dialog box which is described in “Viewing and Manipulating Threads”.

The thread command changes the state of program threads. The following briefly describes the thread command with its options:

In addition, the intercept command can take the following arguments when you are debugging multi-threaded applications:

Finally, some debugger commands allow you to specify a thread by using the -thread option. Those commands are:

activate breakpoints
breakpoint
delete breakpoints
suspend breakpoints
tb

For more information on the commands described in this section, see the online command reference.