Need to put thread safe std::string for GNU g++ 2.95.3 on Solaris 10

Question

std::string is showing thread-unsafe behavior on Soalris 10 (compiled using GNU g++ 2.95.3). Here's my sample program:

#include <iostream>
#include <string>
#include <pthread.h>
#include <stdio.h>
using namespace std;
void *Loop(void *) {
 while(1) {
  string *ps = new string("Hi");
  if (ps == NULL) {
   fprintf(stdout, "string creation failed\n");
}}}
int main (int argc, char **argv) {
 pthread_t thread1, thread2;
 fprintf(stdout, "creating threads\n");
 if(pthread_create(&thread1, NULL, Loop, NULL) == 0)
  fprintf(stdout, "thread 1 created\n");
 if(pthread_create(&thread2, NULL, Loop, NULL) == 0)
  fprintf(stdout, "thread 2 created\n");
  while(1);
  return 0;
}

I compiled the sourcecode (teststl.c) as:

g++ -c teststl.c
g++ -o teststl teststl.o -lthread

Platform and compiler used are:

Platform: Solaris 10
Compiler GNU g++ 2.95.3

When I run it: it shows,

creating threads
thread 1 created
thread 2 created
./runteststl: line 5:  1412 Bus Error               (core dumped) ./teststl 

The following is the dump of the ' pstack core '

core 'core' of 14353:   ./teststl
-----------------  lwp# 1 / thread# 1  --------------------
 00011a7c main     (1, ffbff9cc, ffbff9d4, 232f8, ff2f00c0, 0) + b4
 00011798 _start   (0, 0, 0, 0, 0, 0) + 5c
-----------------  lwp# 2 / thread# 2  --------------------
 000121ec allocate__t24__default_alloc_template2b0i0Ui (20, 20, 23104, 69, 0, 0)
 + a4
 00012220 __nw__Q2t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc
_template2b0i0_3RepUiUi (10, 10, ff000000, 0, 0, 1) + 14
 00012260 create__Q2t12basic_string3ZcZt18string_char_traits1ZcZt24__default_all
oc_template2b0i0_3RepUi (2, 2, ff000000, 2, 1f, fffc00) + 24
 000127a4 replace__t12basic_string3ZcZt18string_char_traits1ZcZt24__default_allo
c_template2b0i0UiUiPCcUi (8df70, 0, ffffffff, 12a48, 2, 80808080) + 114
 00012a24 assign__t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc
_template2b0i0PCcUi (8df70, 12a48, 2, 0, ff1c0200, ff1b9210) + 24
 000129e4 assign__t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc
_template2b0i0PCc (8df70, 12a48, d9fd8, 129e4, ff1b03a8, ff1ba518) + 24
 00012948 __t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_templ
ate2b0i0PCc (8df70, 12a48, 12800, 0, ff1c0200, 1) + 28
 00011908 Loop__FPv (0, ff07c000, 0, 0, 118d0, 0) + 38
 ff148a20 _lwp_start (0, 0, 0, 0, 0, 0)
-----------------  lwp# 3 / thread# 3  --------------------
 000121ec allocate__t24__default_alloc_template2b0i0Ui (20, 20, 23104, 69, 0, 0)
 + a4
 00012220 __nw__Q2t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc
_template2b0i0_3RepUiUi (10, 10, ff000000, 0, 0, 1) + 14
 00012260 create__Q2t12basic_string3ZcZt18string_char_traits1ZcZt24__default_all
oc_template2b0i0_3RepUi (2, 2, ff000000, 2, 1, fffc00) + 24
 000127a4 replace__t12basic_string3ZcZt18string_char_traits1ZcZt24__default_allo
c_template2b0i0UiUiPCcUi (8df60, 0, ffffffff, 12a48, 2, 80808080) + 114
 00012a24 assign__t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc
_template2b0i0PCcUi (8df60, 12a48, 2, 0, ff1c0a00, ff1b9210) + 24
 000129e4 assign__t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc
_template2b0i0PCc (8df60, 12a48, d9fd8, 129e4, ff1b03a8, ff1ba518) + 24
 00012948 __t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_templ
ate2b0i0PCc (8df60, 12a48, 12800, 0, ff1c0a00, 1) + 28
 00011908 Loop__FPv (0, fef7c000, 0, 0, 118d0, 0) + 38
 ff148a20 _lwp_start (0, 0, 0, 0, 0, 0)

This shows a contention problem. Anything to do with the compilation or linking flags? Tried with suggestions from https://docs.oracle.com/cd/E19455-01/806-5257/compile-94179/index.html but that didn't work either. Any suggestions?

Answer 1

The crash happens inside std::allocator , so I assume that is not properly thread-safe in GCC 2.95.3, but I am not going to dig out the ancient code to check.

Stop using such a relic.

Answer 2

Your compile/link switches seem to be incorrect. You need to add -pthreads to both compile and link steps. Without those, thread-unsafe code is used on all levels, including memory allocation.