Debugging threads with HP Wilde Beest

ret_val = pthread_mutex_unlock(&n_mtx);
check_error(ret_val, "mutex_unlock n_mtx");
printf("Thread %d - released n_mtx\n", thread_num);
}
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.
(gdb) set thread-check recursive-relock on
The debugger transfers the execution control to the user and prints a warning message
when this condition is detected.
The following is a segment of the HP WDB output:
Starting program: /home/gdb/enh_thr_mx_relock
Thread 1 - got r_mtx
Thread 1 - got r_mtx
Thread 1 - released r_mtx
Thread 1 - released r_mtx
Thread 1 - got n_mtx
[Switching to thread 2 (system thread 39774)]
warning: Attempt to recursively acquire non-recursive mutex 2 from thread 2.
TIP: Release the lock on a non-recursive mutex before attempting to acquire lock on
the same object again, to avoid this situation.
Problem: The thread attempts to unlock a mutex or a read-write lock that it does not control.
Consider the following scenario: Thread 1 locks mutex A. Thread 2 unlocks mutex A.
This is clearly an attempt from Thread 2 to release the lock on mutex A which was
previously locked by Thread 1.
Consider the following example enh_thr_unlock_not_own.c:
#include pthread.h
#include string.h
#include stdio.h
#include errno.h
pthread_mutex_t mtx = PTHREAD_MUTEX_INITIALIZER;
/* Print error information, exit with -1 status. */
void
fatal_error(int err_num, char *function)
{
char *err_string;
err_string = strerror(err_num);
fprintf(stderr, "%s error: %s\n", function, err_string);
exit(-1);
}
22