From patchwork Thu Aug 30 10:29:51 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Thiago Macieira X-Patchwork-Id: 180812 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 1363D2C024B for ; Thu, 30 Aug 2012 20:30:19 +1000 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1346927420; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: From:To:Subject:Date:Message-ID:User-Agent:MIME-Version: Content-Type:Content-Transfer-Encoding:Mailing-List:Precedence: List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=Grb9yeh2zbyfiwmUdysGD2Xnit8=; b=Km4IT5yBp8webMv 5tbabVCDD2IcPCOfd7Y5Ttqlvyt5jXSHtBX3ox3Yqh0hgPlRIGtWaqgbN1Ahdb4i WDucbvGVhAAvMVsNstTgsvO2UBa5ELTQ3rNWeuJSSoPiocBb/y1HLwIsH2dGhQBY j/a1IUdpszXT0f6qFOIC4YfOHEso= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:X-ExtLoop1:Received:From:To:Subject:Date:Message-ID:User-Agent:MIME-Version:Content-Type:Content-Transfer-Encoding:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=u0QAVlFcSzNdJZAa5hQzPolDn+ptmYTiJWPL2Y6+7XtMq7p9s0QXWbZyiCaVDz o18P3rr3gF5pvAIxhenQR3Fb9Jd/Gn2+qRe+gKWbRVrhrJK+3fR619ceFjjEx7zc lAhpPt5gZBnFazJhkiIkXijWxnzh2EScRFrZSoe//F1uA=; Received: (qmail 15430 invoked by alias); 30 Aug 2012 10:30:09 -0000 Received: (qmail 15407 invoked by uid 22791); 30 Aug 2012 10:30:07 -0000 X-SWARE-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_00, KHOP_RCVD_UNTRUST, RCVD_IN_DNSWL_HI, RCVD_IN_HOSTKARMA_W, RP_MATCHES_RCVD, TW_CX X-Spam-Check-By: sourceware.org Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 30 Aug 2012 10:29:54 +0000 Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 30 Aug 2012 03:29:53 -0700 X-ExtLoop1: 1 Received: from unknown (HELO tjmaciei-mobl2.localnet) ([10.252.121.147]) by fmsmga002.fm.intel.com with ESMTP; 30 Aug 2012 03:29:52 -0700 From: Thiago Macieira To: gcc-patches@gcc.gnu.org, libstdc++@gcc.gnu.org Subject: [PATCH, libstdc++] Fix PR54172 Date: Thu, 30 Aug 2012 12:29:51 +0200 Message-ID: <3027697.Y09XNY3VZT@tjmaciei-mobl2> User-Agent: KMail/4.9 beta1 (Linux/3.5.2-3.fc17.x86_64; KDE/4.8.5; x86_64; git-2bb8395; 2012-06-03) MIME-Version: 1.0 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Hello The attached patch fixes a race condition in __cxa_guard_acquire, a regression from 4.6. When the code was refactored to use the new atomic intrinsics, the fact that __atomic_compare_exchange_n updates the "expected" variable with the current value was missed. That causes the loop to possibly overwrite a successful initialisation and re- start the initialisation phase. The bug report has a gdb trace with a watchpoint showing the guard variable transitioning 0 (uninit) -> 256 (pending) -> 1 (done) -> 256 (pending) -> 1 (done) This situation can happen if both CAS fail in given thread: the first because the other thread started the initialisation and the second because the initialisation succeeded. 2012-08-30 Thiago Macieira PR libstdc++/54172 * libsupc++/guard.cc (__cxa_guard_acquire): Don't compare_exchange from a finished state back to a waiting state. --- libstdc++-v3/libsupc++/guard.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libstdc++-v3/libsupc++/guard.cc b/libstdc++-v3/libsupc++/guard.cc index adc9608..4da9035 100644 --- a/libstdc++-v3/libsupc++/guard.cc +++ b/libstdc++-v3/libsupc++/guard.cc @@ -244,13 +244,13 @@ namespace __cxxabiv1 if (__gthread_active_p ()) { int *gi = (int *) (void *) g; - int expected(0); const int guard_bit = _GLIBCXX_GUARD_BIT; const int pending_bit = _GLIBCXX_GUARD_PENDING_BIT; const int waiting_bit = _GLIBCXX_GUARD_WAITING_BIT; while (1) { + int expected(0); if (__atomic_compare_exchange_n(gi, &expected, pending_bit, false, __ATOMIC_ACQ_REL, __ATOMIC_RELAXED)) -- 1.7.11.4