The std::string implementation that comes with libstdc++ 2.96-98 is not thread safe. The problem will result in a corrupted memory heap. The reason for the problem is improper locking of the reference count in std::basic_string::Rep. The problem is also in the version that comes with GCC v2.95.3, but seems to be fixed in GCC v3.0.4. If STLport is used as the standard library, the problem disappears. I have a test-program that will trigger this: [andrej@hermes tests]$ g++ -Wall -O3 -pthread string_mt.cpp -lstdc++ -lpthread [andrej@hermes tests]$ ./a.out Thread started (1026) Thread started (2051) Thread started (3076) Segmentation fault
Created attachment 49145 [details] Test program
Created attachment 49146 [details] Patch adding locking for i386 machines
Notice that all threaded applications, and all libraries using std::string that can be used in threaded applications must be recompiled.
To restate the severity of this bug -- std::string is worse than just not threadsafe, it is completely unsuitable for any program or library compiled for multithreading and run on an SMP iA32 system. You can crash in nilRep() by just creating empty strings on the stack, as the static nil representation will have its reference count go to zero and be freed. Calling a class threadsafe typically implies that the same instance can be operated upon by different threads. The current implementation of std::string does not allow different instances to be operated on by different threads.
This problem is still present in Red Hat Linux v7.3. gcc-2.96-112 gcc-c++-2.96-112 libstdc++-2.96-112 libstdc++-devel-2.96-112
Fixed gcc-3.2.x, gcc-3.3.x, gcc-3.4.x.