From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 66D0F3858C83; Tue, 18 Oct 2022 18:03:23 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 66D0F3858C83
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1666116203;
	bh=Un3V8qTrJZejgCtMGZS0xR8tM+F6ZXbfH281ZgKRrLU=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=d3y4ts8Hv46rJCfl1sM7+XWOMFr9Hx5Kx0FrgCdDVODYX12Sq7aAkaBOIaubnQaXs
	 mTgW7hSeqqAg1nRYoaqf3c/rckBaS9rjsAaNkmBmFS5ZGDU1uFaVY5Zo1TlYzmPq/r
	 ZjId9F712pTKBJdvDvp43gPiRB7M0Rb4VrLQKupQ=
From: "stsp at users dot sourceforge.net" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug sanitizer/101476] AddressSanitizer check failed, points out a
 (potentially) non-existing stack error and pthread_cancel
Date: Tue, 18 Oct 2022 18:03:21 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: sanitizer
X-Bugzilla-Version: 11.1.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: stsp at users dot sourceforge.net
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-101476-4-XhRE13bR2s@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-101476-4@http.gcc.gnu.org/bugzilla/>
References: <bug-101476-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D101476

--- Comment #18 from Stas Sergeev <stsp at users dot sourceforge.net> ---
(In reply to Stas Sergeev from comment #5)
> And its running on a stack previously
> poisoned before pthread_cancel().

And the reason for that is because
the glibc in use is the one not built
with -fsanitize=3Daddress. When it calls
its __do_cancel() which has attribute
"noreturn", __asan_handle_noreturn()
is not being called. Therefore the
canceled thread remains with the
poison below SP.
I believe the glibc re-built with asan
would not exhibit the crash.

Note: all URLs above where I was pointing
to the code, now either are a dead links
or point to wrong lines. Its quite a shame
that such a bug remains unfixed after a
complete explanation was provided, but now
that explanation is rotten...=