Date: Tue, 19 Apr 2011 22:48:59 -0400 From: Ryan Stone <rysto32@gmail.com> To: David Xu <davidxu@freebsd.org> Cc: FreeBSD Current <freebsd-current@freebsd.org>, Ed Maste <emaste@freebsd.org> Subject: Re: [PATCH] Call _thr_check_init() from _pthread_once Message-ID: <BANLkTin5P7bTvUkSLPDLig8nP8dFQkh49g@mail.gmail.com> In-Reply-To: <4DAE4164.9080006@freebsd.org> References: <BANLkTikwT0qOB32DeLMdFkx4vkx6_HAkQg@mail.gmail.com> <4DAE4164.9080006@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 19, 2011 at 10:13 PM, David Xu <davidxu@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTin5P7bTvUkSLPDLig8nP8dFQkh49g>