This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: mt_allocator: static DE-initialization order fiasco?
On Mon, Oct 11, 2004 at 09:17:40PM -0500, Loren James Rittle wrote:
> I think that because the output you posted with the test case clearly
> has two identical sub-sequences of memory allocation (each
> sub-sequence has the pattern of allocation seen for the C++ library
> initialization). I find that odd. I agree the output of ldd that you
> posted implies nothing about the problem.
The first set
Calling: operator new(258) = 0x804a008 [from 0x4006516e]
Calling: operator new(100) = 0x804a110 [from 0x400651cc]
Calling: operator new(4) = 0x804a178 [from 0x400653a9]
Calling: operator new(4) = 0x804a188 [from 0x400653a9]
Calling: operator new(4) = 0x804a198 [from 0x400653a9]
Calling: operator new(4) = 0x804a1a8 [from 0x400653a9]
Calling: operator new(4) = 0x804a1b8 [from 0x400653a9]
Calling: operator new(4080) = 0x804a1c8 [from 0x400657dc]
Calling: operator new(8) = 0x804b1c0 [from 0x4006581f]
are allocations from
__gnu_cxx::__pool<true>::_M_initialize(void (*)(void*)) (the first 7) and from
__gnu_cxx::__pool<true>::_M_reserve_block(unsigned int, unsigned int) (the last 2).
The second set
Calling: operator new(258) = 0x804b1d0 [from 0x40064ce8]
Calling: operator new(40) = 0x804b2d8 [from 0x40064d34]
Calling: operator new(4) = 0x804b308 [from 0x40064d9d]
Calling: operator new(4) = 0x804b318 [from 0x40064d9d]
Calling: operator new(4) = 0x804b328 [from 0x40064d9d]
Calling: operator new(4) = 0x804b338 [from 0x40064d9d]
Calling: operator new(4) = 0x804b348 [from 0x40064d9d]
Calling: operator new(4080) = 0x804b358 [from 0x400654bd]
Calling: operator new(8) = 0x804c350 [from 0x40065518]
are allocations from
__gnu_cxx::__pool<false>::_M_initialize(void (*)(void*)) (the first 7) and from
__gnu_cxx::__pool<false>::_M_reserve_block(unsigned int, unsigned int) (the last 2).
Both are instantiated in libstdc++ (in libstdc++-v3/src/mt_allocator.cc).
I think it is perfectly normal to see both in this test case.
--
Carlo Wood <carlo@alinoe.com>