Q. about threads and the STL

[Philip Charlton <charlton at ligo dot caltech dot edu>]

Hi,

I've been having a big problem with some code that uses STL objects inside
threads, a "sequence" object derived from valarray<T>.
The code was originally meant to test that some math operations in
threads, specifically, using the FFTW package to perform Fourier
transforms in two threads simultaneously. However, even when I remove all
of the FFT-specific code out I still get the problem.

The behaviour that I'm seeing is that, most of the time, the test program
runs to completion without any problems. But on some occasions (maybe 1
in 10 times) it crashes with a segmentation fault for no apparent reason
and doesn't give a core file. Moreover, this only seems to happen on
Linux SMP boxes with 2 or more CPU's - it has never crashed on my desktop
machine which is a single-processor Linux box.

In trying to track down the problem I've removed much of the
code and am left with two threads, one of which does nothing except assign
a couple of variables, the other which creates a Sequence<float>, which is
basically a valarray<float> plus some other stuff, of length 65536.

(Note: I would include the source here but there is not yet a standalone
version of the code which exhibits the problem - modifying seemingly
unrelated code or even removing functions/code that isn't called seems to
make the problem come and go randomly! I'm working on narrowing it down
further)

Debug output shows that both threads are created, run to completion and
are joined without any problems, and the program is meant to end straight
after both of the threads are joined. I have print statements showing
that the joins are successful - the crashes seem to happen when the
program is unloading, but I don't understand why, unless the problem is
that some global object was corrupted by one of the threads and causes the
program to segfault when global objects are destructed. The problem seems
to go away when I remove the declaration of the Sequence<float>, which
makes me wonder if there is a problem with the way memory is allocated for
it by the STL allocator, although we have definitely configured our gcc
with --enable-threads=posix and even defined __USE_MALLOC in libstdc++-v3.

The system I'm running it on has 4 CPU's and Linux 2.4.6 #1 SMP kernel.
I'm compiling with gcc version 2.95.3 20010315 (release)

If anyone has any advice on this problem I'd like to hear,
particularly insights into why the program would randomly crash AFTER
completing the threads (instead of during, as I would normally expect),
or whether there are issues with gcc, libstdc++ or Linux (particularly
threads in an SMP kernel) that might cause this sort of behaviour.

Thanks
Philip

--
Philip Charlton
California Institute of Technology
LIGO Laboratory 18-34
1200 E. California Blvd
Pasadena CA 91125 USA
Phone: +1 (626) 395 8437
Fax:   +1 (626) 793 9744
mailto:charlton@ligo.caltech.edu
http://www.ligo.caltech.edu/~charlton