Debugging with GDB Manual The GNU Source-Level Debugger (769148-001, March 2014)

To enable a thread, execute the following command:
(gdb) thread enable 1
Enabling thread 1
You can set and view the kernel threads with the help of the following commands:
set show-all-kthreads Sets non-zero integer value so that the gdb reports all the kernel
threads. By default this is set to 0, that means gdb reports only
those kernel threads that are associated with user threads.
show show-all-kthreads Displays the status of current set show-all-kthreads
command.
Backtrace Support for Thread Debugging
The following commands are available as backtrace support for thread debugging:
bt The bt command provides the stack trace of the current thread
that is being executed or the thread that accepts the signal in
case of a core file.
thread apply all bt You can use the thread apply all bt command to display
the backtrace of all threads. The bt command only provides
the stack trace of the current thread under execution.
backtrace_other_thread The backtrace_other_thread command prints the
backtrace of all stack frames for a thread with stack pointer
SP, program counter PC and address of gr32 in the backing
store BSP. This command enables you to view the stack trace
when the stack is corrupted. When using this command, you
must ensure that the SP, PC, and BSP values are valid.
The syntax for the backtrace_other_thread command is
as follows:
backtrace_other_thread SP PC BSP
Advanced Thread Debugging Support
Advanced thread debugging support is available for multi-threaded applications running on HP-UX
11iv2, or HP-UX 11iv3.
HP WDB 5.5 and later versions provide advanced thread debugging features to display extended
information on the state of pthread primitives such as mutexes, read-write locks and conditional
variables.
HP WDB 5.6 and later versions provide advanced thread-debugging options to detect the following
thread-related conditions:
• The thread attempts to acquire a non-recursive mutex that it currently holds.
• The thread attempts to unlock a mutex or a read-write lock that it has not ac- quired.
• The thread waits (blocked) on a mutex or read-write lock that is held by a thread with a different
scheduling policy.
• Different threads non-concurrently wait on the same condition variable, but with different
associated mutexes.
• The thread terminates execution without unlocking the associated mutexes or read-write locks.
• The thread waits on a condition variable for which the associated mutex is not locked.
• The thread terminates execution, and the resources associated with the terminated thread
continues to exist in the application because the thread has not been joined or detached.
134 HP-UX Configuration-Specific Information