|
From: Philippe W. <phi...@sk...> - 2012-06-04 18:43:49
|
On Mon, 2012-06-04 at 14:14 +0200, Christoph Bartoschek wrote:
> Am 04.06.2012 14:00, schrieb Tom Hughes:
> > On 04/06/12 12:27, Christoph Bartoschek wrote:
> >
> >> how should one interpret the following report:
> >>
> >> Thread #11: Bug in libpthread: recursive write lock granted on
> >> mutex/wrlock which does not support recursion
> >> ==00:13:17:12.428 20623== at 0x4C2D18D: pthread_spin_lock (in
> >> /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so)
> >>
> >>
> >> Is there a bug in libpthread that does something strange? Or is there a
> >> bug in my program that tries to lock a lock twice?
> >
> > It's saying that the program is trying to lock a mutex which is (a)
> > already locked and (b) not marked as a recursive mutex.
> >
> > So yes, something is trying to lock the same mutex twice.
> >
> > Whether it is your program at fault is hard to say for sure without
> > seeing the rest of the stack trace.
The pthread_mutex_lock manual says:
"If the mutex type is PTHREAD_MUTEX_DEFAULT, attempting to recursively
lock the mutex results in undefined behavior."
So, one of the possible outcome of the undefined behaviour is to give
the lock. Valgrind then reports this as a bug in the pthread library
(even if this is not formally a bug, according to the manual).
But of course, the above is only ok if your program effectively
tries to lock recursively a non recursive mutex.
> however I wonder that the message does not mention where the lock was
> aquired for the first time.
You might try --tool=drd --trace-mutex=yes --trace-rwlock=yes
to have more details about what is happening.
Philippe
|