[Bug nptl/25847] pthread_cond_signal failed to wake up pthread_cond_wait due to a bug in undoing stealing

[frankbarrus_sw at shaggy dot cc]

https://sourceware.org/bugzilla/show_bug.cgi?id=25847

--- Comment #39 from Frank Barrus <frankbarrus_sw at shaggy dot cc> ---
(In reply to Qin Li from comment #34)
> Hi Frank, I am the original reporter of this bug. Could you share a sneak
> peak version of your alternate fix that you mentioned below?
> 
> > FYI, I'm currently testing a different pthreads fix for this issue that does it without the suggested "broadcast" solution that some distros appear to be adopting for now.
> 
> The reason I am asking is that several months after applied the broadcast
> fix we started to observe a different hang caused by either
> pthread_cond_signal/pthread_cond_wait, or the constructs it relied on, e.g.
> futex. Original I feared it is related or caused by the broadcast fix, but
> later realized this might be another issue as it has also been independently
> reported in this bug by Arun without applying the broadcast fix:
> https://sourceware.org/bugzilla/show_bug.cgi?id=25847#c3
> 
> The signature of this different issue is this: 1 thread blocked "infinitely"
> in the pthread_cond_signal when calling __condvar_quiesce_and_switch_g1:
> 
> #0  futex_wait
> #1  futex_wait_simple
> #2  __condvar_quiesce_and_switch_g1
> #3  __pthread_cond_signal
> 
> And all the other threads are blocked in pthread_cond_wait waiting for the
> signal.
> 
> Another interesting observation is the "infinitely" blocked thread on
> pthread_cond_signal can be unblocked if I send a SIG_SEGV to the linux .Net
> Core process that hit this issue which has a segfault handler that will call
> another external executable to take a core dump of this process. I am not
> exactly sure how much of the special signal handling logic is important to
> get pthread_cond_signal unblocked. It is possible that such signal would
> cause a spurious wakeup from futex_wait that actually unblocks
> __condvar_quiesce_and_switch_g1 and later __pthread_cond_signal, but this is
> pure speculation.
> 
> It would be nice to know if the ^^^ hanging pthread_cond_signal signature
> has also been discovered by the community and whether there might be any
> investigation/fix available.

Hi Qin,

I just posted the current version of my proposed fix.  (see previous comment
and attachment)
This will address your second concern as well, since it removes the need for
condvar_quiesce_and_switch_g1() to block.

Please try the patch and let me know how it goes for your testing.
Thanks!
- Frank

-- 
You are receiving this mail because:
You are on the CC list for the bug.