This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

STL mt_allocator crash in global construcutor



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]