https://bugs.kde.org/show_bug.cgi?id=445743
Bug ID: 445743
Summary: "The impossible happened: mutex is locked
simultaneously by two threads" while using mutexes
with priority inheritance and signals
Product: valgrind
Version: 3.16.0
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: drd
Assignee: bart.vanassche+...@gmail.com
Reporter: vladimir.niko...@aicas.de
Target Milestone: ---
Created attachment 143727
--> https://bugs.kde.org/attachment.cgi?id=143727&action=edit
Example to reproduce the issue.
SUMMARY
***
The provided example shows two threads synchronizing on a mutex, which has been
initialized with the PTHREAD_PRIO_INHERIT protocol. While the contender is
blocked on pthread_mutex_lock() the owner of the mutex sends a signal to the
contender via pthread_kill(). While running under valgrind supervision with
--tool=drd --trace-mutex=yes "The impossible happened: mutex is locked
simultaneously by two threads" is reported and the example terminates
unexpectedly.
***
STEPS TO REPRODUCE
Compile the example with -O0 and run with valgrind with --tool=drd
--trace-mutex=yes enabled.
OBSERVED RESULT
When run outside valgrind the example does not terminate. This is expected
behavior.
However, when run with valgrind's memcheck tool the program terminates. This
seems to be already wrong.
Furthermore, when run with valgrind's drd tool the impossible happens:
$ valgrind --tool=drd ./mutex_signal
==264795== drd, a thread error detector
==264795== Copyright (C) 2006-2017, and GNU GPL'd, by Bart Van Assche.
==264795== Using Valgrind-3.16.0 and LibVEX; rerun with -h for copyright info
==264795== Command: ./mutex_signal
==264795==
mutex initialized
thread attributes initialized
contender trying to lock mutex
thread created
sleeping
signalling
joining thread
nullHandler running
==264795== Thread 2:
==264795== The impossible happened: mutex is locked simultaneously by two
threads: mutex 0x1ffefff850, recursion count 1, owner 1.
==264795== at 0x4C3F298: pthread_mutex_lock_intercept
(drd_pthread_intercepts.c:893)
==264795== by 0x4C3F298: pthread_mutex_lock (drd_pthread_intercepts.c:903)
==264795== by 0x400BE3: contender_start (mutex_signal.c:16)
==264795== by 0x4C3BB48: vgDrd_thread_wrapper (drd_pthread_intercepts.c:449)
==264795== by 0x4E5E149: start_thread (in /usr/lib64/libpthread-2.28.so)
==264795== by 0x5172DC2: clone (in /usr/lib64/libc-2.28.so)
==264795== mutex 0x1ffefff850 was first observed at:
==264795== at 0x4C3E2C4: pthread_mutex_init_intercept
(drd_pthread_intercepts.c:826)
==264795== by 0x4C3E2C4: pthread_mutex_init (drd_pthread_intercepts.c:835)
==264795== by 0x400D34: main (mutex_signal.c:48)
==264795==
contender locked mutex
contender unlocking mutex
contender unlocked mutex
==264795== Thread 1:
==264795== Mutex still locked at thread exit: mutex 0x1ffefff850, recursion
count 1, owner 2.
==264795== at 0x4C3CB26: pthread_join_intercept
(drd_pthread_intercepts.c:716)
==264795== by 0x4C3CB26: pthread_join (drd_pthread_intercepts.c:723)
==264795== by 0x400E91: main (mutex_signal.c:74)
==264795== mutex 0x1ffefff850 was first observed at:
==264795== at 0x4C3E2C4: pthread_mutex_init_intercept
(drd_pthread_intercepts.c:826)
==264795== by 0x4C3E2C4: pthread_mutex_init (drd_pthread_intercepts.c:835)
==264795== by 0x400D34: main (mutex_signal.c:48)
==264795==
==264795==
==264795== For lists of detected and suppressed errors, rerun with: -s
==264795== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 158 from 148)
EXPECTED RESULT
When run outside valgrind the example does not terminate.
When run outside valgrind the mutex is not locked by both threads when the
signal is sent.
$ ./mutex_signal
mutex initialized
thread attributes initialized
thread created
sleeping
contender trying to lock mutex
signalling
joining thread
nullHandler running
SOFTWARE/OS VERSIONS
Linux 4.18.0-305.19.1.el8_4.x86_64 #1 SMP Wed Sep 15 15:39:39 UTC 2021 x86_64
x86_64 x86_64 GNU/Linux
CentOS Linux release 8.4.2105
ADDITIONAL INFORMATION
This issue was reproduced also with latest valgrind-3.19.0.GIT
--
You are receiving this mail because:
You are watching all bug changes.
