mt_allocator: static DE-initialization order fiasco?

[Loren James Rittle]

Carlo Wood  <carlo@alinoe.com> wrote:
>> |Therefore, if you are getting into serious troubles using __mt_alloc
>> directly, the same will happen if you just use std::allocator. Consider
>> that mt_allocator is now the default in the build, therefore, if you
>> just select the right policy via a typedef in include/ext/mt_allocator.h
>> and rebuild the library you can very easily double check what I said.

>> Please, if you have a small testcase contribute it.

> Ugh that wasn't easy :/.
[...]
> As you can see, the object "foo.cc" is using memory at 0x804b394
> that falls in the range [0x804b358 - 0x804c348) of a memory block
> that already freed.

It appears that additional context may be involved with this bug.
FWIW, I see no failure on i386-unknown-freebsd4.  The test runs as
expected.

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?

Regards,
Loren