Debugging with GDB Manual HP WDB v6.3 (5900-2180, August 2012)

The advanced thread debugging features can be enabled only if the set thread-check [on]
command is enabled. The following advanced thread debugging options are available for the
set thread-check command:
recursive-relock [on|off] This set thread-check recursive-relock
[on|off] command checks if a thread has attempted to
acquire a non-recursive mutex that it currently holds.
Re-locking a non-recursive mutex results in a deadlock. At
run-time, the debugger keeps track of each mutex in the
application and the thread that currently holds each mutex.
When a thread attempts to acquire a lock on a non-recursive
mutex, the debugger checks if the thread currently holds the
lock object for the mutex. The debugger transfers the
execution control to the user and prints a warning message
when this condition is detected.
unlock-not-own [on|off] The set thread-check unlock-not-own [on|off]
command checks if a thread has attempted to unlock a mutex
or a read-write lock that it has not acquired. The debugger
transfers the execution control to the user and prints a
warning message when this condition is detected.
mixed-sched-policy [on|off] The set thread-check mixed-sched-policy
[on|off] command checks if a thread is waiting (blocked)
on a mutex or a read-write lock that is held by a thread with
a different scheduling policy. This is not an application error
and does not always result in deadlock. However, it
degrades the application performance. The debugger
transfers the execution control to the user and prints a
warning message when this condition is detected.
cv-multiple-mxs [on|off] The set thread-check cv-multiple-mxs [on|off]
command checks if an application uses the same condition
variable in multiple calls, by different threads to
pthread_cond_wait() or
pthread_cond_timedwait(), but specifies different
mutexes. The debugger transfers the execution control to
the user and prints a warning message when this condition
is detected.
All threads that concurrently wait on any single condition
variable must specify the same associated mutex. For
example,the pthread implementation does not allow
thread 1 to wait on condition variable A by
specifying mutex A, while thread 2 waits on the same
condition variable A by specifying mutex B. This
returns an EINVAL error to the application. In contrast to
this obvious EINVAL error, the cv-multiple-mxs option
detects the less-obvious and non-concurrent use of multiple
mutexes with the same condition variable by different
threads. This option detects potential EINVAL errors that
exist as a result of different timings or execution paths.
This option is used to detect unintentional use of multiple
mutexes with the same condition variable by different
threads. In the case of applications that use a dynamic pool
of mutexes, the cv-multiple-mxs option is not required
because this usage is normal and expected application
behavior.
142 HP-UX Configuration-Specific Information