From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22155 invoked by alias); 10 Oct 2012 13:17:39 -0000 Received: (qmail 22147 invoked by uid 22791); 10 Oct 2012 13:17:38 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from bromo.med.uc.edu (HELO bromo.med.uc.edu) (129.137.3.146) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 10 Oct 2012 13:17:33 +0000 Received: from bromo.med.uc.edu (localhost.localdomain [127.0.0.1]) by bromo.med.uc.edu (Postfix) with ESMTP id DC4B6B004B; Wed, 10 Oct 2012 09:17:32 -0400 (EDT) Received: (from howarth@localhost) by bromo.med.uc.edu (8.14.3/8.14.3/Submit) id q9ADHVmX011947; Wed, 10 Oct 2012 09:17:31 -0400 Date: Wed, 10 Oct 2012 13:27:00 -0000 From: Jack Howarth To: Jason Merrill Cc: Dominique Dhumieres , gcc-patches@gcc.gnu.org, ro@CeBiTec.Uni-Bielefeld.DE Subject: Re: RFC: C++ PATCH to support dynamic initialization and destruction of C++11 and OpenMP TLS variables Message-ID: <20121010131731.GA11897@bromo.med.uc.edu> References: <20121009140751.4F52F3BE1B@mailhost.lps.ens.fr> <20121009144314.GA1406@bromo.med.uc.edu> <50744261.2000404@redhat.com> <20121009203614.E060A3BABA@mailhost.lps.ens.fr> <5074CBA2.7020801@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5074CBA2.7020801@redhat.com> User-Agent: Mutt/1.5.18 (2008-05-17) Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2012-10/txt/msg00989.txt.bz2 On Tue, Oct 09, 2012 at 09:13:06PM -0400, Jason Merrill wrote: > On 10/09/2012 04:36 PM, Dominique Dhumieres wrote: >> ==36994== Address 0x1003cd2e0 is 16 bytes inside a block of size 536 free'd >> ==36994== at 0x10001252D: free (vg_replace_malloc.c:430) >> ==36994== by 0x1003B5CB2: emutls_destroy (in /opt/gcc/gcc4.8p-192219/lib/libgcc_s.1.dylib) > > Aha. So the problem is that we're destroying the TLS data from one > pthread key destructor, and then a later destructor tries to use it. > Hmm, that's awkward. And surprising, since we do TLS lookup before > creating the key for the atexit list, so the emutls_destroy destructor > should have been registered sooner, and so run later. Does the Darwin > pthread_tsd_cleanup not run destructors in reverse order of registration? Jason, Have you tried a gcc trunk build on linux configured to use emutls instead of tls to confirm that this issue is really darwin-specific? These failures might also appear on sparc-sun-solaris2.9 but we don't have recent gcc trunk testresults for that. Perhaps Rainer can try a build of current gcc trunk and see if it impacts sparc-sun-solaris2.9's use of emutls as well. Jack > > Jason