|
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
|