|
From: Christoph B. <bar...@or...> - 2012-06-04 11:49:52
|
Hi, 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? Thanks Christoph |
|
From: Tom H. <to...@co...> - 2012-06-04 12:01:04
|
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. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Christoph B. <bar...@or...> - 2012-06-04 12:16:33
|
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.
Thanks,
however I wonder that the message does not mention where the lock was
aquired for the first time.
This is how the complete message looks like:
Thread #14: Bug in libpthread: recursive write lock granted on
mutex/wrlock which does not support recursion
at 0x4C2D18D: pthread_spin_lock (in
/usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so)
by 0x67B8E9: legos::spin_np_t::lock__default(legos::spin_np_t*) (in
nutsh-O)
by 0xE1E7F30: IJMQueue::remove(IJMPropertyOwner*, int) (in src-O.dll)
by 0xE1E4CD5: IJMTimingPoint::removeATQ() (in src-O.dll)
by 0x105D3577: IJMHierBox::theATQueueThreadFunc(void*) (in engine-O.dll)
by 0x4C2C03D: ??? (in
/usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so)
by 0x503DF04: start_thread (in /lib64/libpthread-2.14.1.so)
by 0x5CAD10C: clone (in /lib64/libc-2.14.1.so)
Christoph
|
|
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
|
|
From: Christoph B. <bar...@or...> - 2012-06-05 16:05:23
|
Am 04.06.2012 20:44, schrieb Philippe Waroquiers:
> 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).
I am sure that the spin lock is not used recursively because the code
basically looks like this:
mutex m;
int data = 0;
int func()
{
m.lock();
int ret = ++data;
m.unlock();
return ret;
}
This is the only occurence of the lock.
> 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.
I am afraid of the billions of lines in the logfile before the problem
occurs.
Christoph
|
|
From: Philippe W. <phi...@sk...> - 2012-06-05 20:40:44
|
On Tue, 2012-06-05 at 18:03 +0200, Christoph Bartoschek wrote:
> I am sure that the spin lock is not used recursively because the code
> basically looks like this:
>
> mutex m;
> int data = 0;
>
> int func()
> {
> m.lock();
> int ret = ++data;
> m.unlock();
> return ret;
> }
>
> This is the only occurence of the lock.
Well, then that looks like a real bug in the pthread lib
(or a bug in the Valgrind simulation e.g. of atomic instructions use
by the pthread lib ?).
If you have a small reproducer, that will help to dig into the problem.
Otherwise, gdb on Valgrind and/or Valgrind gdbserver might help
you to see what is going (wrong).
Philippe
|