https://bugs.kde.org/show_bug.cgi?id=445504
--- Comment #5 from Paul Floyd <pjfl...@wanadoo.fr> ---
I'm trying to understand how this is working.
Main thread:
other_thread:
Create 'state' on the stack, initializes mutex and CV
Create a thread, other_thread, via std::async
Wait for 1 second
lock mutex
wait for 3 second on CV, also unlocks mutex
lock mutex
2 vector push backs
unlock mutex
CV notify
CV notified
break and fall off end of thread function
cleanup
I don't get the same errors (GCC 9.3 on RHEL7)
With DRD (I've trimmed loads of stack):
==494== Command: ./valgrind_test
==494==
Other thread: waiting for notify
==494== Probably a race condition: condition variable 0x1ffeffeb00 has been
signaled but the associated mutex 0x1ffeffeac0 is not locked by the signalling
thread.
by 0x4027CE: main (valgrind_test.cpp:53)
cond 0x1ffeffeaf0 was first observed at:
by 0x4025A7: other_thread(state*) (valgrind_test.cpp:22)
mutex 0x1ffeffeab0 was first observed at:
by 0x402572: other_thread(state*) (valgrind_test.cpp:20)
With Helgrind:
==677== Thread #1: pthread_cond_{signal,broadcast}: dubious: associated lock is
not held by any thread
==677== at 0x4036146: pthread_cond_broadcast_WRK (hg_intercepts.c:1501)
==677== by 0x4AEA0E8: __gthread_cond_broadcast (gthr-default.h:853)
==677== by 0x4AEA0E8: std::condition_variable::notify_all()
(condition_variable.cc:73)
==677== by 0x402778: main (valgrind_test.cpp:48)
If I comment out the braces around the lock_guard and push_backs in main then I
get no error.
--
You are receiving this mail because:
You are watching all bug changes.
