This is the mail archive of the
glibc-bugs@sources.redhat.com
mailing list for the glibc project.
[Bug nptl/300] pthread_cond_timedwait does not reacquire the mutex on cancelation
- From: "rth at redhat dot com" <sourceware-bugzilla at sources dot redhat dot com>
- To: glibc-bugs at sources dot redhat dot com
- Date: 11 Aug 2004 18:51:21 -0000
- Subject: [Bug nptl/300] pthread_cond_timedwait does not reacquire the mutex on cancelation
- References: <20040805081906.300.sebastien.decugis@ext.bull.net>
- Reply-to: sourceware-bugzilla at sources dot redhat dot com
------- Additional Comments From rth at redhat dot com 2004-08-11 18:51 -------
Subject: Re: pthread_cond_timedwait does not reacquire the mutex on cancelation
On Mon, Aug 09, 2004 at 09:42:30PM -0000, jakub at redhat dot com wrote:
> 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?
I dunno. Perhaps Uli Weigand is right and we should handle
all of this +- 1 signal stuff in MD_FALLBACK_FRAME_STATE_FOR.
Recall that signals like SIGILL and the like will tend to
point to the *next* instruction, so if you did the +1
unconditionally, now you're pointing pass the next insn, so
you could have moved to a different EH region.
I see no solution that is sure to be 100% correct.
r~
--
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.