Re: [PATCH] Call _thr_check_init() from _pthread_once

On 2011/04/20 10:48, Ryan Stone wrote:
> On Tue, Apr 19, 2011 at 10:13 PM, David Xu <davidxu_at_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
> 

OK, I understand, that current INPROGRESS will push cleanup routine, so
the curthread is used, your patch is right.