From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 03:04:48 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFD2F106566C; Wed, 20 Apr 2011 03:04:48 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9B72B8FC08; Wed, 20 Apr 2011 03:04:48 +0000 (UTC) Received: from xyf.my.dom (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p3K34iEi005364; Wed, 20 Apr 2011 03:04:46 GMT (envelope-from davidxu@freebsd.org) Message-ID: <4DAE4D53.7080602@freebsd.org> Date: Wed, 20 Apr 2011 11:04:51 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.13) Gecko/20110127 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ryan Stone References: <4DAE4164.9080006@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , Ed Maste Subject: Re: [PATCH] Call _thr_check_init() from _pthread_once X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 03:04:48 -0000 On 2011/04/20 10:48, Ryan Stone wrote: > On Tue, Apr 19, 2011 at 10:13 PM, David Xu wrote: >> Have you tested that current code causes segfault ? >> anyway, I can not reproduce it on my machne. >> >> Regards, >> David Xu > > Yes, I had an application where libstdc++ was calling pthread_once > while constructing a static object. As near as I can tell it's pure > luck as to whether you'll hit this crash or not. If the linker > happens to place a static initializer that calls pthread_once first in > the list of static initializers, you crash. If instead something far > more likely like pthread_mutex_lock is called first, you're fine. > > The backtrace for my executable was something like: > #0 0x684dadd4 in _pthread_once (once_control=0x6887fdcc, > init_routine=0x6883d740 <__gthread_trigger()>) > at /usr/src/lib/libthr/thread/thr_once.c:84 > #1 0x6883d992 in __gthread_active_p () > at /tmp/buildutils.x86/x86-i686-pc-freebsd8/i686-pc-freebsd8/libstdc++-v3/include/i686-pc-freebsd8/bits/gthr-default.h:221 > #2 __eh_globals_init () > at gcc/libstdc++-v3/libsupc++/eh_globals.cc:98 > #3 __static_initialization_and_destruction_0 () > at gcc/libstdc++-v3/libsupc++/eh_globals.cc:110 > #4 global constructors keyed to eh_globals.cc(void) () > at gcc/libstdc++-v3/libsupc++/eh_globals.cc:146 > #5 0x68848d06 in __do_global_ctors_aux () > from /usr/local/mumble/lib/libstdc++.so.6 > OK, I understand, that current INPROGRESS will push cleanup routine, so the curthread is used, your patch is right.