https://bugs.kde.org/show_bug.cgi?id=327548

--- Comment #14 from Samuel Thibault <samuel.thiba...@ens-lyon.org> ---
FYI, it's glibc 2.36:

- pthread_mutex_lock.c:94 is when it checks assert (mutex->__data.__owner ==
0); after obtaining the lock
- pthread_mutex_lock.c:182 is when it sets mutex->__data.__owner after
obtaining the lock
- pthread_mutex_unlock.c:62 is when it clears mutex->__data.__owner before
releasing the lock
- pthread_mutex_unlock.c:65 is when it --mutex->__data.__nusers; before
releasing the lock

The other cond-related lines are more complex to describe, but they'll probably
get fixed the same way as mutex would get fixed.

I guess the disabling of checking somehow perturbates helgrind's history record
(I guess that's part of the "This puts it in the same state as new memory
allocated by this thread -- that is, basically owned exclusively by this
thread." comment for the VALGRIND_HG_ENABLE_CHECKING macro)

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to