gcc 2.95.4 MT related crashes in basic_string class

[Karel Gardas <kgardas at objectsecurity dot com>]

Hello,

yes, I know gcc 2.95.4 is quite old, but we are still using it for
development (because of compilation speed) and for testing. It looks quite
stable so far, but last week, I've found strange problem with stability of
code while using it in multi-threaded environment under load (MICO - CORBA
implementation).

Part of problematic backtrace looks:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 3076 (LWP 29874)]
0x409a81b7 in memcpy () from /lib/libc.so.6
(gdb) bt
#0  0x409a81b7 in memcpy () from /lib/libc.so.6
#1  0x408e4130 in string_char_traits<char>::copy () from /usr/lib/libstdc++-libc6.2-2.so.3
#2  0x08059cb7 in basic_string<char, string_char_traits<char>, __default_alloc_template<true, 0> >::Rep::copy (this=0x40e00008,
    pos=0, s=0x805e834 "", n=134604836) at /usr/lib/gcc-lib/i386-linux/2.95.4/../../../../include/g++-3/std/bastring.cc:139
#3  0x08059fdc in basic_string<char, string_char_traits<char>, __default_alloc_template<true, 0> >::replace (this=0xbf3ff710,
    pos=134604836, n1=0, n2=1, c=47 '/') at /usr/lib/gcc-lib/i386-linux/2.95.4/../../../../include/g++-3/std/bastring.cc:201
#4  0x0805a114 in basic_string<char, string_char_traits<char>, __default_alloc_template<true, 0> >::append (this=0xbf3ff710, n=1,
    c=47 '/') at /usr/lib/gcc-lib/i386-linux/2.95.4/../../../../include/g++-3/std/bastring.h:202
#5  0x0805a240 in basic_string<char, string_char_traits<char>, __default_alloc_template<true, 0> >::operator+= (this=0xbf3ff710,
    c=47 '/') at /usr/lib/gcc-lib/i386-linux/2.95.4/../../../../include/g++-3/std/bastring.h:241
#6  0x404afb6d in MICOPOA::POAObjectReference::decompose_ref (this=0xbf3ff6f0) at poa_impl.cc:753
#7  0x404afe4f in MICOPOA::POAObjectReference::is_legal (this=0xbf3ff6f0) at poa_impl.cc:797


As you can see last two frames are from MICO. The problem is that
POAObjectReference instance is protected by pthread mutex and to my best
knowledge the operation decompose_ref is thread-safe. The crash happened
when there were two different instances invoked at the same time by two
distinct threads. Anyway after spending nearly whole day trying to find
problem, I've tried to recompile whole tree with gcc 3.2.2 and duplicate
crash there. I can only say, that till now, I'm not able to do it and it
has been tested under high-load on some SMP servers during the whole week.

So from this point of view gcc3.2.2 looks _very_ good, although I hate
slowness of this compiler, but it really seems that we need to switch.

What I just would like to know is if there are/were really some MT related
bugs/races in the old libstd++ as it's packaged in gcc2.95.4 for example
on Debian 3.0:

thinkpad:~/arch$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
gcc version 2.95.4 20011002 (Debian prerelease)
thinkpad:~/arch$


Thanks a lot,

Karel
--
Karel Gardas                  kgardas@objectsecurity.com
ObjectSecurity Ltd.           http://www.objectsecurity.com