Re: libstdc++/4219: stl_alloc using -D__USE_MALLOC fails

[bjornw at planetarion dot com (Bjørn Wennberg)]

ljrittle@gcc.gnu.org writes:

> Synopsis: stl_alloc using -D__USE_MALLOC fails
> 
> Responsible-Changed-From-To: unassigned->ljrittle
> Responsible-Changed-By: ljrittle
> Responsible-Changed-When: Tue Sep  4 14:02:27 2001
> Responsible-Changed-Why:
>     Look like mine.
> State-Changed-From-To: open->feedback
> State-Changed-By: ljrittle
> State-Changed-When: Tue Sep  4 14:02:27 2001
> State-Changed-Why:
>     BTW, I think it would be a good idea to make the
>     change you spotted.
>     
>     Is there a reason why you can't follow this advice on
>     the new way to use the malloc interface in your application
>     (from ./include/bits/c++config but see the primary
>     documentation on the matter as well):
>     

Nothing would please me more than seeing this work out. Now I did report
this problem when egcs was at is feet but noone really had decent small
programs for tracking the problem. 

My prioritizes are
1. Get all third-party vendor C++ code to work with new compiler
   (seems to work OK without __USE_MALLOC as expected (same for gcc-2))
2. Get gcc-3.X to compile my hundreds of thousands of lines.
   Getting there, but still there is a problem related to
   constructor-initializing (simplified) such as
   
   class CDbExpr {
     public:
       CDbExpr(const CDbExpr &);
   };

   And initializing CDbExpr(CDbExpr(CDbExpr..... doesn't work. Never
   has after egcs-1.1.2 if I recall. Think I did see this in the most
   (un)popular bugreports in your system :-)

   I need to rewrite alot of expressions in order to make my system behave
   BEFORE I can even start testing removing __USE_MALLOC for good.

   (and of course streams-rewrite)

3. Remove __USE_MALLOC which is my number#1 motivation for switching 
   to gcc-3.X compiler.

>     // Default to the typically high-speed, pool-based allocator (as
>     // libstdc++-v2) instead of the malloc-based allocator (libstdc++-v3
>     // snapshots).  See libstdc++-v3/docs/html/17_intro/howto.html for
>     // details on why you don't want to override this setting.  Ensure
>     // that threads are properly configured on your platform before
>     // assigning blame to the STL container-memory allocator.  After doing
>     // so, please report any possible issues to libstdc++@gcc.gnu.org .
>     // Do not blindly #define __USE_MALLOC here or on the command line.
>     
>     The problem with users defining __USE_MALLOC on the command
>     line is that it is a subtle ABI change that may cause you
>     problems...
> 
> http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=4219&database=gcc
> 

I have a database-proxy object which must live 'forever' and supports multiple
threads (connection pooling) in addition to creating new threads for accepting
incoming requests. Now - mixing maps/list/vectors/strings and pthreads and
the super-duper allocators from gcc-2 releases started to leak 4 bytes exactly
per threaded connection (in a few words). I did really try alot of memory
detectors, self-written memory checkers etc etc; narrowing the problem. But
if the examples where to simple - I was unable to reproduce this behaviour.
More or less the answer I got from the egcs-ppl. 

I will of course test the system (after either you fix the ctor-initializer
well-known-bug, or I take the time to rewrite alot of code - could take
some time as this might change binary-tree patterns in my code). 

I did a test where I wrote my own string and list classes - but that didn't
fix the problem. I didn't start rewriting maps/vectors and such since I didn't
have the time and because I think there had to be some obvious 'spinlock problem'
somewhere in the old allocators when using pthreads.

Willing to test - but can't share the code :-/

bjornw>
-- 
------------------------------------------------------------------------
    bjornw@planetarion.com  Bjørn Wennberg, Fifth Season AS