On 19 January 2013 18:26, Juan Carlos Franzoy wrote:
> Thanks for reading my question.
>
> I'm experiencing a dealock in the initialization of a static variable
> X defined inside a function Y called in the program static
> initialization.
>
> The problem, as far as I suppose ("as far as I know" would be an
> exaggeration), is that gcc protects the the expression that
> initializes X
> from it beeing initialized concurrently by another thread and Y get
> called reentrantly.
>
> The question to answer would be, why is Y called reentrantly?
[...]
> =
> = 4th breakpoint fired in static initialization of a.cpp ??? Fired
> from CCC constructor inside c.cpp (c.so) static initialization
> =
> = This is THE mistery from my ignorant point of view.
> = Why is a.cpp static initialization called inside CCC ctor?
Lets assume global constructors for objects in c.so happen to run
first, which agrees with your debugging session.
That will construct the global CCC ccc, calling CCC::CCC() calls
bbb1(), which initializes a static AAA, so executes AAA::AAA(int),
which is in a.so so causes the static constructors from a.so to be
run, which initializes the global DDD object, which runs DDD:DDD()
which calls bbb1() which recursively tries to initialize the local
static AAA. Boom.
This might be preventable if you can somehow arrange for the static
constructors from a.so to run first.
This seems to be what happens when I run your code on GNU/Linux:
bbb1(10)
AAA::AAA(10)='0x7fc9346f42f8'
AAA::get()='0x7fc9346f42f8'
CCC::CCC()='0x7fc9348f6e68' bbb1(10)=10
bbb1(10)
AAA::get()='0x7fc9346f42f8'
DDD::DDD()='0x7fc934af8430' bbb1(10)=10
> = there is two threads
> =
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
> (gdb) info threads
> * 2 Thread 1 0xfece9019 in __lwp_park () from /lib/libc.so.1
> 1 LWP 1 0xfece9019 in __lwp_park () from /lib/libc.so.1
Why are there two threads?
Is it just a single thread, contained in a single LWP?
