From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id DDABB3858CDB; Wed, 21 Sep 2022 18:30:08 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DDABB3858CDB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1663785008; bh=Gml0l+K7KLL74nhUSuppBaqzt3eTJwpYvpAQjZOm908=; h=From:To:Subject:Date:In-Reply-To:References:From; b=rpRKr1tRXwNZJPM00w0DamuwCPeY8lwquF6SdA2mTvnkEd6wOyZa3vN/mFf5Uf8PA 7aCm8tkOoH/Vm7Sq4H3kCr6Efdx5JuU93cmYtd81ZuZwPxMZ3FGC0pxTFA3ybZpm3F p6i6BtLhZlGbr9nmsUk7oz0Tr0TMn6xiUjPNsUoo= From: "paul.groke at dynatrace dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/54185] [4.7/4.8 Regression] condition_variable not properly destructed Date: Wed, 21 Sep 2022 18:30:06 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libstdc++ X-Bugzilla-Version: 4.7.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: paul.groke at dynatrace dot com X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: redi at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.7.2 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: 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: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D54185 Paul Groke changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |paul.groke at dynatrace do= t com --- Comment #16 from Paul Groke --- (In reply to Jonathan Wakely) > It fails reliably on AIX too. I think that is because of non-conformant behavior of AIX's pthread_mutex_destroy. It will return EBUSY as long as there are still thre= ads executing a wait function, even if they're already blocked on re-acquiring = the mutex. If you ignore the error and simply releases/unmap the memory of the = CV, you have a good chance of getting a SIGSEGV in the wait function later (aft= er it has re-acquired the mutex and presumably proceeds to mark the CV "non-busy"). In our tests, we get the EBUSY every time if we delete the CV while holding= the mutex on the same thread. The SIGSEGV also reproduces quite well, although = for some reason only with 32 bit builds. (AIX 7.1, oslevel 7100-05-03-1837)=