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.
