https://bugs.kde.org/show_bug.cgi?id=392331
--- Comment #2 from faminebad...@googlemail.com ---
> Do you have a small compilable reproducer ?
I tried to make a cut-down version, but then it didn't reproduce. Such is the
nature of debugging races I guess.
However, it's quite clear from the glibc source code that
pthread_cond_wait_common (the common implementation for both pthread_cond_wait
and pthread_cond_timedwait) can call pthread_cond_signal after releasing the
lock by calling __condvar_cancel_waiting, which contains:
> __condvar_release_lock (cond, private);
>
> if (consumed_signal)
> {
> /* We effectively consumed a signal even though we didn't want to.
> Therefore, we need to send a replacement signal.
> If we would want to optimize this, we could do what
> pthread_cond_signal does right in the critical section above. */
> __pthread_cond_signal (cond);
> }
>}
It even implicitly says it's outside of the critical section.
This suggests some interaction between waiting and cancelling that wait via a
signal or interrupt.
Either way though, I don't think this should be flagged as an error by
valgrind, given it's purely internal to glibc, and is presumably working as
intended.
--
You are receiving this mail because:
You are watching all bug changes.
