mt_allocator: static DE-initialization order fiasco?

[Carlo Wood]

The static initialization order fiasco is wellknown, but
something similar can occur when global or static objects
are being destructed.

In the current CVS HEAD, the default implementation of
the STL allocator (mt_alloc) is using static objects
for the memory pool instances.  When these instances
are being destructed they delete the memory that is
still in use by the pool.

As a result, access of memory by for example an STL
container or a std::string object, that is static
or global and which is destructed later, might access
freed memory and possibly cause a segmentation fault.

This might normally not occur because libstdc++ is
the last C++ that is deinitialized (that destructs it
global objects).  But it is certainly true for
memory pools that a user would add to its own application,
using the provided __per_type_pool_policy for example.
Considering the two underscores I can imagine that
this is not something a user should use (neither __mt_alloc),
but still.  It is rather publically documented
(on http://gcc.gnu.org/onlinedocs/libstdc++/ext/mt_allocator.html)
so I am a bit confused about if this is really how
we want this to work.

The only solution that I can think of is to add some
kind of reference counter, and only then destruct the
memory pools when the last object that use an allocator
that uses that pool is destructed.

-- 
Carlo Wood <carlo@alinoe.com>