From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3999 invoked by alias); 11 Aug 2004 18:51:21 -0000 Mailing-List: contact glibc-bugs-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sources.redhat.com Received: (qmail 3982 invoked by alias); 11 Aug 2004 18:51:21 -0000 Date: Wed, 11 Aug 2004 18:51:00 -0000 Message-ID: <20040811185121.3981.qmail@sourceware.org> From: "rth at redhat dot com" To: glibc-bugs@sources.redhat.com In-Reply-To: <20040805081906.300.sebastien.decugis@ext.bull.net> References: <20040805081906.300.sebastien.decugis@ext.bull.net> Reply-To: sourceware-bugzilla@sources.redhat.com Subject: [Bug nptl/300] pthread_cond_timedwait does not reacquire the mutex on cancelation X-Bugzilla-Reason: CC X-SW-Source: 2004-08/txt/msg00113.txt.bz2 List-Id: ------- 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.