Re: mt_allocator (rev 1.28) has static initilization problems?

[Brad Spencer <spencer at infointeractive dot com>]

On Tue, May 18, 2004 at 05:01:46PM +0200, Paolo Carlini wrote:
> Hi Brad and sorry for late replying.
> 
> For now, I want to simply add that probably I'm also seeing something
> similar, on a 4-way x86_64 system. It's very difficult to reproduce, but 
> this
> is the symptom:
> 
> 0x00000000004027e6 in __gnu_cxx::__mt_alloc<int>::deallocate (this=0x64, 
> __p=0x401ffa10, __n=245)
>    at mt_allocator.h:448
> 448                     __tmp = __tmp->_M_next;
> 
> As you can see, __n = 245, therefore, the code looping on __tmp = 
> __tmp->_M_next
> should not be executed at all! The only plausible explanation is that
> _S_options._M_max_bytes is stuck at zero (as you reported) sigh!
> 
> I'm now studying the details of your message. Do you have any news,
> anyway?

Unfortunately, I don't have much news; I've been pulled in other
directions by other work.

BTW, the box I'm using is uni-processor and my application is
single-threaded. 

<ramblings>
My current suspicion is that static initialization seems to happen in
the reverse order of library specifications on the link line, which
would cause one to expect libstdc++ to happen before user code.  But I
think the fact that this is a template (possibly on arbitrary user
types, even) means that the initialization gets "scheduled" later,
where it's instantiated.  But this is all conjecture.
</ramblings>

I thought about trying to set the __attribute__((init_priority)) on
the static members of mt_allocator to force them to be initialized
earlier (how early?).  I'm not sure if this is enough, though, and
I haven't had a chance to try yet.  I can try out any suggestions,
though, to see if they work on sparc-sun-solaris2.8.  

I've also been running real code and exercising full applications for
two weeks built with the same compiler/libstdc++ and have seen no
problems.  I don't think the same pattern (STL containers in
namespace scope) is used in these applications, though. 

-- 
------------------------------------------------------------------
Brad Spencer - spencer@infointeractive.com - "It's quite nice..."
Systems Architect | InfoInterActive Corp. | A Canadian AOL Company