gcc 2.95.4 MT related crashes in basic_string class

gcc 2.95.4 MT related crashes in basic_string class

[Karel Gardas]

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

Re: gcc 2.95.4 MT related crashes in basic_string class

[Gabriel Dos Reis]

Karel Gardas <kgardas@objectsecurity.com> writes:

[...]

| 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:

Hi, 

  the C++ runtime support that shipped with GCC-2.95.x (epecially the
string implementation) is known not to work in multi-threading
environment.  GCC-3.x is much much better (even if the front-end is
slow).  

-- Gaby

Re: gcc 2.95.4 MT related crashes in basic_string class

[Benjamin Kosnik]

>  the C++ runtime support that shipped with GCC-2.95.x (epecially the
>string implementation) is known not to work in multi-threading
>environment.  GCC-3.x is much much better (even if the front-end is
>slow).  

Dudes,

If I had a dime for every time this question was asked, even though it's
on the FAQ, or for every time some person tried to get 2.90.8 up on
gcc-2.x and failed, or for every time some huge MT app in some
impossible-to-reproduce, crazy hardware situation telecom/financial
testing lab failed due to v2 MT string issues but passed with v3......

... there would be free empanadas and bordeaux for everybody.

;)

-benjamin

Re: gcc 2.95.4 MT related crashes in basic_string class

[Karel Gardas]

On Mon, 10 Feb 2003, Benjamin Kosnik wrote:

>
> >  the C++ runtime support that shipped with GCC-2.95.x (epecially the
> >string implementation) is known not to work in multi-threading
> >environment.  GCC-3.x is much much better (even if the front-end is
> >slow).
>
> Dudes,
>
> If I had a dime for every time this question was asked, even though it's
> on the FAQ, or for every time some person tried to get 2.90.8 up on
> gcc-2.x and failed, or for every time some huge MT app in some
> impossible-to-reproduce, crazy hardware situation telecom/financial
> testing lab failed due to v2 MT string issues but passed with v3......
>
> ... there would be free empanadas and bordeaux for everybody.
>
> ;)

Indeed, sorry! So I'll start complain more about gcc3.x c++ compilation
speed problems on this list... :-) And perhaps I'll provide some time
statistic for our typical code...

Thanks,

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

Re: gcc 2.95.4 MT related crashes in basic_string class

[Phil Edwards]

On Mon, Feb 10, 2003 at 12:58:25PM -0600, Benjamin Kosnik wrote:
> Dudes,
> 
> If I had a dime for every time this question was asked, even though it's
> on the FAQ, or for every time some person tried to get 2.90.8 up on
> gcc-2.x and failed, or for every time some huge MT app in some
> impossible-to-reproduce, crazy hardware situation telecom/financial
> testing lab failed due to v2 MT string issues but passed with v3......

No kidding.


> ... there would be free empanadas and bordeaux for everybody.

"there would be free- what the..."

    http://www.foodreference.com/html/fempanadas.html

Oh.  Sweet.  I should try making those.


-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
                                                 - Edsger Dijkstra, 1930-2002