mt_allocator: static DE-initialization order fiasco?

[Carlo Wood]

On Mon, Oct 11, 2004 at 08:16:33PM -0500, Loren James Rittle wrote:
> It appears that additional context may be involved with this bug.

Of course - that typical for a 'deinitialization order fiasco bug'
the order is undetermined - it probably depends on the version of
binutils used and maybe more :/

I cannot make a test case that will fail on ALL platforms without
also testing it there... and I only have one box to do tests on.

> FWIW, I see no failure on i386-unknown-freebsd4.  The test runs as
> expected.

Try moving the Global.cc file to one of the other libraries and play
a bit with the order in which you link the libraries.

> Looking at your ./a.out output vs.  mine, I see a major problem with
> your output.  Based on object allocation size and sequence only, it
> appears to be initializing two copies of the standard library.  Any
> idea why that would be happening in your environment?  What does
> 'ldd ./a.out' display?

I don't understand why you think that.

$ ldd ./a.out
        linux-gate.so.1 =>  (0xffffe000)
        libglobal1.so => libglobal1.so (0x40018000)
        libfoo.so => libfoo.so (0x4001d000)
        libglobal2.so => libglobal2.so (0x40023000)
        libstdc++.so.6 => /usr/local/gcc-cvs-4.0/lib/libstdc++.so.6 (0x40028000)
        libm.so.6 => /lib/tls/libm.so.6 (0x40111000)
        libgcc_s.so.1 => /usr/local/gcc-cvs-4.0/lib/libgcc_s.so.1 (0x40134000)
        libc.so.6 => /lib/tls/libc.so.6 (0x4013e000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

-- 
Carlo Wood <carlo@alinoe.com>