Debugging threads with HP Wilde Beest

Starting program: /home/gdb/enh_thr_cv_wait_no_mx
[Switching to thread 2 (system thread 39559)]
warning: Attempt by thread 2 to wait on condition variable 0 without locking the associated mutex
1.
0x800003ffeffcc608 in __rtc_pthread_dummy+0 () from ../librtc64.sl
NOTE: This is an additional check that HP WDB provides and is not a POSIX.1
standard requirement for the pthread_cond_wait() routine.
You can determine the function which attempts to wait on the condition, by looking
at the batcktrace(bt) of the thread that is reported above.
TIP: Modify the code segment of the function so it acquires control over the mutex
associated to the conditional variable before it calls the routine,
pthread_cond_wait().
Problem: The thread terminates execution, and the resources associated with the thread continue
to exist in the application because the thread has not been joined or detached.
Consider the following scenario:
Thread A in an application terminates execution successfully or as a result of an
exception/cancel. The resources associated with the thread exist in the application until
the thread is joined or detached.
Consider the following example enh_thr_exit_no_join_detach.c:
#include pthread.h
#include stdlib.h
#include errno.h
pthread_mutex_t job_lock1 = PTHREAD_MUTEX_INITIALIZER;
extern void fatal_error(int err, char *f);
void
my_thread(void* num)
{
int ret_val;
/* Acquire the associated mutex lock */
if ((ret_val = pthread_mutex_lock(&job_lock1)) != 0)
fatal_error(ret_val, "p mtx_lock failed");
printf ("In thread %d\n", (int) num);
/* Release the associated mutex */
if ((ret_val = pthread_mutex_unlock(&job_lock1)) != 0)
fatal_error(ret_val, "mtx_unlock failed");
}
#define check_error(return_val, msg) { \
if (return_val != 0) \
Modes of Thread debugging in HP WDB 33