STL mt_allocator crash in global construcutor

[Neil Bird <neil at fnxweb dot com>]

  FC4, g++ (GCC) 4.0.2 20051125 (Red Hat 4.0.2-8)

  We have a no. of libraries which have worked fine up till now (even using
4.0.1 on FC3, albeit with libstdc++-3.4.4-).  Now with 4.0.1 (& 4.0.2)'s
libstdc, I'm getting a crash immediately at start-up in mt_allocator.h, within
_M_adjust_freelist:

      void
      _M_adjust_freelist(const _Bin_record& __bin, _Block_record* __block,
                         size_t __thread_id)
      {
        if (__gthread_active_p())
          {
            __block->_M_thread_id = __thread_id;
HERE ->     --__bin._M_free[__thread_id];
            ++__bin._M_used[__thread_id];
          }
      }

  At the point at which it happens, _M_free is uninitialised.  This is
constructing a class static deque within a dlopen()'d shared library.


  I'm guessing that the order of global constructors is altered by the
dependancy linkage, and that this constructor is being called before the pool
allocator's [I can't find the body code for the pool template's
_M_initialize() anywhere ...].

  But I don't have any idea how to work around it, or even be sure whether
it's our code or the STL.

  I did discover that GLIBCXX_FORCE_NEW=1 at runtime makes it not crash, but
it then seems to make the code behave very oddly (I get problems I've never
had before).


  I've contructed a cut-down example of this.  It is a /tad/ convoluted
(three small libraries, one of which is null), but it seems as if any attempt
to further simplify the code makes the problem go away (including makeing it
less libaries [even dropping the null one] and removing any one of the members
of 'CVersion'):

  http://www.fnxweb.com/data/stl-crash.tbz

  A 'make' in the top level of the above will compile & exhibit the problem;
 a 'make symbolcheck' thereafter will just run the small one-liner that crashes.


  It *seems* to be a libstdc++ problem, as (above) it works flawlessly with
my 4.0.1 running on FC3 but the older libstdc++, plus I can compile that on
FC3 and then run it OK on an FC4 box, so I don't think it's the runtime
linker.  It *could* feasably be 'ld' itself, though.

--
[neil@fnx ~]# rm -f .signature
[neil@fnx ~]# ls -l .signature
ls: .signature: No such file or directory
[neil@fnx ~]# exit