[Bug nptl/300] pthread_cond_timedwait does not reacquire the mutex on cancelation

["jakub at redhat dot com" <sourceware-bugzilla@sources.redhat.com>]

------- Additional Comments From jakub at redhat dot com  2004-08-09 21:42 -------
This seems to be a bug on the GCC side.
The test only seems to fail if SIGCANCEL signal interrupts the worker thread
on the very first instruction of __pthread_disable_asynccancel function
(FYI compiled with -fasynchronous-unwind-tables), called from
pthread_cond_timedwait.S.
MD_FALLBACK_FRAME_STATE_FOR sets (FS)->regs.reg[8].loc.offset to address
where __pthread_disable_asynccancel+0 is stored, during uw_update_context
this results in context->ra being set to __pthread_disable_asynccancel+0.
The problem is that next uw_frame_state_for will
fde = _Unwind_Find_FDE (context->ra - 1, &context->bases);
but context->ra - 1 is __pthread_disable_asynccancel-1 which isn't covered by
.eh_frame (and if it would, it would be for a different function).

So, to me it looks like MD_FALLBACK_FRAME_STATE_FOR should ensure that
context->ra will be set to pctx->uc_mcontext.gregs[REG_IP] + 1, not just
pctx->uc_mcontext.gregs[REG_IP].
Richard, do you agree?
If so, the question is how to ensure it.  I remember MD_FALLBACK_FRAME_STATE_FOR
used to have ugly hacks to store an incremented address somewhere and point
(FS)->regs.reg[8].loc.offset to it.  But the hacks can't be too ugly, since
they need to be used in both MD_FALLBACK_FRAME_STATE_FOR and in kernel vDSO's
sigreturn .eh_frame description too.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rth at gcc dot gnu dot org


http://sources.redhat.com/bugzilla/show_bug.cgi?id=300

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.