Regression test for thread safety?

[dank@kegel.com]

Loren James Rittle wrote:
> > we're running into a nasty heap corruption problem
> > when using gcc3.0.2's stl in a multithreaded application.
> 
> How did you configure GCC?  We need the exact command line you used.

../gcc-3.0.2/configure --target=powerpc-linux --prefix=/opt/hardhat/devkit/ppc/405 --with-headers=/opt/hardhat/devkit/ppc/405/target/usr/include --enable-shared
--enable-long-long --enable-threads=posix --enable-langugages=c,c++ --with-cpu=403 --nfp

(full script at http://www.kegel.com/build-gcc3.sh , builds on top of hardhat linux 2.0)

> We also need to know the thread model as reported by ``gcc -v''.

$ ${IXIA_GCC3_CROSS_TOOL}g++ -v
Reading specs from /opt/hardhat/devkit/ppc/405/lib/gcc-lib/powerpc-linux/3.0.2/specs
Configured with: ../gcc-3.0.2/configure --target=powerpc-linux --prefix=/opt/hardhat/devkit/ppc/405
--with-headers=/opt/hardhat/devkit/ppc/405/target/usr/include --enable-shared --enable-long-long --enable-threads=posix --enable-langugages=c,c++ --with-cpu=403
--nfp
Thread model: posix
gcc version 3.0.2

It's, um, a bit muddled to install gcc3 on top of the gcc2.9.5 shipped
with Hard Hat 2.0, but that's what we've been doing.  
(I'm slowly debugging a new build script that builds binutils/gcc3.0.4/glibc
from scratch; it's at http://www.kegel.com/xgcc3/, but that's not what
I'm testing now.)

The bug we're seeing could be the app's fault, too.  BTW, defining
_USE_MALLOC sees to make the problem go away, at least in initial tests.

Anything obvious jump out at you? 

> Speaking about the SGI STL portion of libstdc++ only, GCC 3.0 was the
> first release to use gcc's concept of thread model support.
> 
> Not many ports supported threading by default in the GCC 3.0.X
> releases.  The situation changed by GCC 3.1, with more and more ports
> enabling thread support by default.  Before GCC 3.1, the testsuite
> actually had zero tests related to threading.

I've been going on the assumption that my next logical upgrade
from gcc3.0.2 is gcc3.0.4, but haven't really checked whether gcc3.1 
might be better (e.g. is it 'approved' yet for compiling
the Linux kernel for ppc405, ppc750, and sh4?).

> To answer a question raised during follow-up: The six threading tests
> do not claim to spot all threading issues.  In fact, by their very
> nature, most threading failures are non-deterministic.  In practice,
> at least some of the tests have been designed to stress the key
> implementation point of threading support and a test will likely fail
> when mutex region locking is not functional or enabled properly in the
> library implementation.  Some thread tests exercise the per-CPU spin
> lock implementation which supports other parts of libstdc++-v3 (but
> not the SGI STL portion).

Right.  I'm just very glad there are any threading tests at all!

Thanks very much for your reply.
- Dan