STL mt_allocator crash in global construcutor

Neil Bird neil@fnxweb.com
Fri Dec 2 10:37:00 GMT 2005


   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 deque with the following code:


<.h>
#include <string>
#include <deque>

class CObject
{
     public:
         struct SDeadObject
         {
             void *Ptr;
             std::string Name;

             SDeadObject()  { Ptr = NULL; Name = ""; }
             SDeadObject( void *ptr, const std::string &name )  {
                Ptr = ptr; Name = name; }
             };

         typedef std::deque<SDeadObject> DEAD_OBJECT_DEQUE;
         typedef std::deque<SDeadObject>::iterator DEAD_OBJECT_DEQUE_ITERATOR;

     protected:
         static DEAD_OBJECT_DEQUE         RecentlyDeadObjects;
};

<.cpp>
CObject::DEAD_OBJECT_DEQUE      CObject::RecentlyDeadObjects;


   Now, if I create a library with /just/ this code it, and dlopen() it, it 
works OK.  However, if I link that library to my other two base libraries, I 
get the crash.

   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 work OK.


g++ -MMD -Wall   -fmessage-length=0 -ggdb    -fpic   -D_GNU_SOURCE 
-DPROJECT=Buffy -I../../../Buffy    -D__posix -DDISABLE_CF_HACKS  -o 
Linux-i686/Debug/jobby.lo -c jobby.cpp  && cp -f Linux-i686/Debug/jobby.d 
Linux-i686/Debug/jobby.dep  && sed -e 's/#.*//' -e 's/^[^:]*: *//' -e 's/ 
*\\$//' -e '/^$/ d' -e 's/$/ :/' <Linux-i686/Debug/jobby.d 
 >>Linux-i686/Debug/jobby.dep  && rm -f Linux-i686/Debug/jobby.d

g++ -shared  -o ../../../Libs/Buffy/Linux-i686/Debug/libCF.so 
-L../../../Libs/Buffy/Linux-i686/Debug   -Wl,-rpath=/software/lib 
-Wl,-rpath=/mnt/software/lib 
-Wl,-rpath-link=../../../Libs/Buffy/Linux-i686/Debug 
Linux-i686/Debug/jobby.lo -lPSUtils


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



More information about the Gcc mailing list