Red Hat Bugzilla – Bug 61486
std::string not thread safe
Last modified: 2007-04-18 12:41:02 EDT
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
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
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)
Created attachment 49145 [details]
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.
Fixed gcc-3.2.x, gcc-3.3.x, gcc-3.4.x.