g++-1.39.0 malloc problem

[dixons%phvax.dnet at SMITHKLINE.COM]

Dr. Roberto Togneri writes:
>>At last!
>>  I have got g++-1.39 and libg++-1.39 installed on our Sparc2 (4.1.1) and
>>our 4D/20 iris (3.1d). In both cases a proper malloc is important and the
>>GNU malloc should not be used (i.e. define NO_LIBGXX_MALLOC in the libg++
>>Makefile).
>>
>>Here is the problem:
>>
>>1. If I use the GNU malloc both the iris and sun g++ give me a clobbered
>>space detected error when running some c++ programs written by a colleague.
>>The Sun passes make tests; the iris doesn't. If I use the system malloc then
>>there is no core dump for the Sun g++ but I get a segmentation fault for the
>>iris g++. dbx indicates that the fault occurred during the malloc call. In
>>fact this is one of the reasons the iris g++ fails the make tests.
>>
>>Does that mean that the system malloc on the iris isn't up to scratch?
>>Or is there still a definite problem with g++ on an iris (mips) ?
>>(BTW I have tried the OSF version of gcc and g++ but it has the same
>>problem)
I looked a little at the malloc issue with the OSF version of g++ and I 
suspect the same problem is in version 1.39.  What I found by looking at
the code generated was that in some cases, the same memory area was being
freed twice.  The gnu malloc routines (at least the version with OSF) 
caught that as a problem since they do some crude error checking on
the area to be freed/allocated.  System mallocs don't necessarily do this, 
but also may not be hurt by freeing an already freed area.  I suspect,
however, that sometimes this causes the seg faults and other problems
which turn up in the libg++ tests for example.  I believe that the
OSF and gnu 1.39 versions have the same MIPS support and that this is
a generic problem with the MIPS implementation.  I looked a little
at the SUN4 implementation and did not find the same double deallocation
code generated.  I emailed my findings to the person who is listed in
the comments as doing the MIPS g++ work but never heard back.  I'm
afraid that coming up with a fix is more than I want to tackle.
Perhaps someone else has gotten further...
Scott Dixon (dixons at smithkline.com)