Debugging with GDB (February 2008)

Chapter 14: HP-UX Configuration-Specific Information 159
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.
• cv-wait-no-mx [on|off]
The set thread-check cv-wait-no-mx [on|off] checks if the associated mutex
of a condition variable is locked when the thread calls the pthread_cond_wait()
routine. The debugger transfers the execution control to the user and prints a
warning message when this condition is detected. This check is not a POSIX.1
standard requirement for the pthread_cond_wait() routine. It is an additional
check provided by WDB.
• thread-exit-own-mutex [on|off]
The set thread-check thread-exit-own-mutex [on|off] command checks if
any thread has terminated execution without unlocking the mutexes or read-write
locks that are associated with the thread. The debugger transfers the execution
control to the user and prints a warning message when this condition is detected.
This situation can result in deadlocks if other threads are waiting to acquire the
locked mutexes or read-write locks.
• thread-exit-no-join-detach [on|off]
The set thread-check thread-exit-no-join-detach [on|off] command
checks if a thread has terminated execution (either successfully or because of an
exception or a cancel) without joining or detaching the thread. The debugger
transfers the execution control to the user and prints a warning message when
this condition is detected. The resources associated with a terminated thread
continue to exist in the application if the thread is not joined or detached. The
thread must be explicitly joined or detached, or it must be created with the
detach attribute. When an application repeatedly creates threads without a
join or detach operation, the application leaks resources. This may result in
application failure.
• stack-util [num]
The set thread-check stack-util [num] command checks if any thread has used
more than the specified percentage [num] of the stack allocation. The debugger
transfers the execution control to the user and prints a warning message when this
condition is detected. You can use this option to verify if there is a margin of safety
in stack utilization by the threads. The application must ensure that the thread
stack size is sufficient for all the operations of the thread. Each thread is assigned
a stack allocation when it is created. If the stack allocation is not specified for a
thread, the default value is used. The stack allocation cannot be modified after a
thread is created. If a thread attempts to use more stack space than the allocated
stack space, it results in a stack overflow. Stack overflow can result in memory
access violations, bus errors, or segmentation faults.
• num-waiters [num]
The set thread-check num-waiters [num] command checks if the number of
threads waiting on any pthread object exceeds the specified threshold number