From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 4A5363858C31; Wed, 25 Jan 2023 10:17:21 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4A5363858C31 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1674641841; bh=Q4+9zLVxJuM07ytk2KpcerStN3LovtYBdIlJg5b2okA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=IhKnzd5X+KQXjg+sLXUZF79IS00r3jd3xEPGzyN1V1f73GySTGklatVWuTTOXznTo 4vy8EcUMtkyr8LRmTYKdwfaL1H8OpVUVnm834C8ZC8MCwlLQ1fbYp+hPVMwF/TPebD xV8PPFOxzVsDCqqf+ZFTT7CiFrahIKXc9HJ+zMY0= From: "stsp at users dot sourceforge.net" To: glibc-bugs@sourceware.org Subject: [Bug nptl/30041] pthread_cancel() hangs on aarch64 Date: Wed, 25 Jan 2023 10:17:20 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: nptl X-Bugzilla-Version: 2.36 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: stsp at users dot sourceforge.net X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D30041 --- Comment #8 from Stas Sergeev --- (In reply to Andreas Schwab from comment #7) > If anything this is a bug in the debugger. There are two concurrent types > of events, the signal and the shlib events, and the constant flow of sign= al > events prevents the shlib event from making forward progress. Yes, this seems to be the case. I modified the test so that the second thread disables the timer after some time. If pthread_cancel() was hanging, it unstucks. If pthread_join() was hanging, it doesn't unstuck because actually the second thread is already terminated so the timer shut-down doesn't happen. But I thought I excluded such a possibility by at least 2 things: - attaching with gdb and doing "handle SIGALRM nopass" - lowering the SIGALRM rate and making sure both threads can execute code and print things. So I still don't understand what's going on. If both threads could sleep() and printf() relatively happily under the much higher SIGALRM rate, then why some rather small SIGALRM rate still causes pthread_cancel() to stall indefinitely? Its not like anything else stalls. In fact, I discovered that effect on a real program of mine, which works perfectly (and is used by people) under the exact SIGALRM rate which causes the full stall of pthread_cancel(). So how is that possible w/o a bug? --=20 You are receiving this mail because: You are on the CC list for the bug.=