This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: question about __cxa_guard_acquire and static variables in the scope of a function
On Mon, May 9, 2011 at 4:36 PM, Ian Lance Taylor <iant@google.com> wrote:
> Brendan Miller <catphive@catphive.net> writes:
>
>> In G++ 4.1.2 one of my coworkers thinks he's seeing a case where the
>> second time __cxa_guard_acquire is called, it does not block, but just
>> throws an exception. Could someone please clarifies whether this is
>> the expected behavior?
>
> No, but it's perhaps worth noting that this code has been rewritten
> since 4.1.2. ?The 4.1.2 code was buggy when the initializer of a static
> variable started a new thread which in turn tried to initialize the
> static variable itself.
>
> Ian
>
Interesting. Unfortunately, I'm stuck on red hat, and so have to use
older versions of G++. I'd much rather be running 4.6.
We don't seem to have any recursion in our stack trace. I assume that
it is __gnu_cxx::recursive_init being thrown, as that's the only thing
that __cxa_guard_acquire can throw.
Here's the relevant part of the stack trace:
#0 0x00d13410 in __kernel_vsyscall ()
#1 0x00252df0 in raise () from /lib/libc.so.6
#2 0x00254701 in abort () from /lib/libc.so.6
#3 0x001c4530 in __gnu_cxx::__verbose_terminate_handler() () from
/usr/lib/libstdc++.so.6
#4 0x001c1f35 in ?? () from /usr/lib/libstdc++.so.6
#5 0x001c12ca in ?? () from /usr/lib/libstdc++.so.6
#6 0x001c1d99 in __gxx_personality_v0 () from /usr/lib/libstdc++.so.6
#7 0x005647e6 in ?? () from /lib/libgcc_s.so.1
#8 0x00564e2b in _Unwind_RaiseException () from /lib/libgcc_s.so.1
#9 0x001c209d in __cxa_throw () from /usr/lib/libstdc++.so.6
#10 0x001c2375 in __cxa_guard_acquire () from /usr/lib/libstdc++.so.6
I figure acquire_1 is being inlined.
It doesn't look like the relevant static variable initializer is
starting a new thread, and it doesn't look like there's recursion. If
anyone knows of other limitations or bugs in the 4.1.2
__cxa_guard_acquire, it would be greatly appreciated.