C++ stringstream in multithreaded environment

Question

We are using a lot of stringstream objects in multiple locations in our code. The objects are not shared across threads but still program crashes in multithreaded environment. The investigation shows that the program crashes when we use both insertion & extraction operators (stringstream ::operator << and stringstream ::operator >> ). The program crashes at random locations, always pointing to stringstream in our code. We receive SIGBUS, or SIGSEGV or (sometimes) SIGABRT signals.
We need to know how to use stringstream in Multithreaded environment.
Any help will be highly appreciated.
Versions:
Compiler Version: CC: Sun C++ 5.9 SunOS_sparc Patch 124863-05 2008/06/03
Machine: SunOS bear 5.10 Generic_127111-11 sun4u sparc SUNW,Sun-Fire-V490
/usr/lib/sparcv9/libCstd.so.1: Sun SUNWlibC SunOS 5.10 Patch 119963-08 2006/09/20
Following is the test program (creates 20 threads & does insertion-extraction) & Makefile below it.:
{color:#0000ff}#include <string>
#include <sstream>
#include <pthread.h>
#include <thread.h>
#include <vector>
using namespace std;
extern "C" void* ThreadFunc( void* p )
for(int i=0 ; i < 1000000 ; i++){
string str("dummy");
stringstream buf;
buf << "Dummy Data " << i ;
buf >> str;
return NULL;
int main (int argc, char** argv)
try {
pthread_t thread;
vector<pthread_t> threads;
for(int i=0; i < 20 ; i++) {
pthread_create(&thread, NULL,ThreadFunc, NULL);
threads.push_back(thread);
int rc;
void* status;
for(int t=0; t < 10; t++) {
rc = pthread_join(threads[t], &status);
if (rc) {
// cout << "ERROR in joining thread " << threads[t] << endl;
return (-1);
//cout << "Completed joining thread " << threads[t] << " with status " << (long)status << endl;
} catch (...) {
//cout << "some exception\n";
return 0;
{color}
////////Makefile/////////////
{color:#ff00ff}CC=/appl/toolbox/studio12-July08/SUNWspro/bin/CC
CPP =${CC} -m64 -mt -xarch=sparcvis2 -g
OFILES = ${SOURCE:.cpp=.o}
PROG = stringstreamtest
SOURCE = main.cpp
{color}
{color:#ff00ff}${PROG}:${OFILES}
${CPP} ${OFILES} -o $@
%.o:%.cpp
${CPP} -c $< -o $@
{color}
{color:#ff00ff}clean:
${RM} *~
${RM} *.o
${RM} -r ${PROG}
${RM} -f .make.state
.KEEP_STATE:{color}

Answer 1

The stringstream class is thread-safe, but you must provide your own guards around string and stream objects that are shared among threads. That is, the library provides internal guards that you could not provide yourself, but if two threads modify the same string object (or any non-atomic object, for that matter) at the same time, the results are unpredictable.
You have a rather old version of libCstd on your system. Please update to the current SUNWlibC patch
sparc: 119963-12
x86 : 119964-12
You can get the patch from [http://sunsolve.sun.com]
Some other things to check:
Be sure that libCrun and libCstd are linked only as shared (.so) libraries, and not as archive (.a) libraries.
Do not use the linker -Bsymbolic option when creating shared libraries - it can cause program crashes particularly when using the string class.
Do not use -xarch=v8 or -xtarget=v8 options, since it can cause loss of thread synchronization when running on current architectures. (The v8 architecture dates from before the UltraSPARC was introduced in the mid 1990's.)
Finally, you should check your code for the usual programming errors that can lead to crashes:
- using an invalid pointer
  - uninitialized
  - dangling (points to object that no longer exists)
  - incremented or decremented outside object bounds
  - points other than to an object start address
- deleting an object more than once
- reading or writing outside object bounds
- failing to guard shared object in multi-threaded code
- race condition in multi-threaded codeThe program failure usually occurs far away in space and time from the
actual error.
These errors do not always lead to a program crash. An invalid pointer
might sometimes by accident point to a harmless location. A race
condition can go millions of cycles without causing a problem. Access to
a deleted object can succeed by accident if the memory was not re-used.
Any change in program code or compiler options can turn one of these
programming errors into an actual failure, or the other way around.
Try running the program under dbx with Run-Time Checking enabled. RTC
will find many of these errors. In Sun Studio 12, the Thread Analyzer
tool will find race conditions.