From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26613 invoked by alias); 9 Aug 2004 21:42:31 -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 26593 invoked by uid 48); 9 Aug 2004 21:42:30 -0000 Date: Mon, 09 Aug 2004 21:42:00 -0000 Message-ID: <20040809214230.26592.qmail@sourceware.org> From: "jakub 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/msg00067.txt.bz2 List-Id: ------- 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.