在使用GNU 2.95.3的Solaris 10上的多线程C ++程序中，当一个线程试图调用字符串构造函数而其他线程调用stringbuf构造函数时，我遇到了争用问题，如下所述： 一个线程正在调用
__t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0PCc
即。
basic_string<char, string_char_traits<char>, __default_alloc_template<false, 0>>::basic_string(char const *)
另一个线程正在调用
__9stringbufRCt12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0i
即
stringbuf::stringbuf(basic_string<char, string_char_traits<char>, __default_alloc_template<false, 0> > const &, int)
最终，两个线程都会导致为字符串或stringbuf分配空间（如果适用），并导致争用导致SIGBUS错误。
任何线索？
我是否需要重载malloc或new以使其成为线程安全的，或者我是否需要重载string和stringbuf以确保线程安全？
我使用g ++链接器标志如下：
我g++ -g -lclntsh -ldl -lsocket -lrt –lthread
我是否需要添加＆＃39; g++ -pthread＆＃39;在编译期间？我希望这也会添加-D_RENENTRANT。但Solaris g ++ 2.95.3不支持-pthread
这里有更多的pstack核心输出：
core 'core' of 28477:
----------------- lwp# 1 / thread# 1 --------------------
fcb48ac4 __lwp_park (0, 0, fcbb74c4, 1c00, 0, 0) + 14
ff375244 sem_wait (1da56fd8, 1da56c00, 8ea400, 2aae33d0, fcbb49cc, 0) + 20
....
001965f0 _start (0, 0, 0, 0, 0, 0) + 5c
----------------- lwp# 2 / thread# 2 --------------------
fcb4c714 _lwp_kill (a, fed84948, 0, 1, fffffffc, 0) + 8
fdfd6c6c skgesigOSCrash (fc3eea54, fc3ee8fc, ff031460, fef7536c, bc0f4, bc000) + 4c
fe5253a0 kpeDbgSignalHandler (fc3eea54, 2b200cd8, 9e800, a, fc3eee5d, 6060000) + 2f0
fdfd71ac skgesig_sigactionHandler (a, fc3ef6e0, fefef8f8, 0, ff0314a0, fc3eea40) + f0
fcb48b4c __sighndlr (a, fc3ef6e0, fc3ef428, fdfd70bc, 0, 1) + c
fcb3d1f8 call_user_handler (a, 0, 8, 0, fc540200, fc3ef428) + 3b8
fcb3d3cc sigacthandler (a, fc3ef6e0, fc3ef428, 1, fc540200, 0) + 4c
--- called from signal handler with signal 10 (SIGBUS) ---
00608e00 allocate__t24__default_alloc_template2b0i0Ui (20, 20, 9eff80, 1c7be, 2ab11e06, fcbb4f18) +
a4
003cde3c __nw__Q2t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0_3RepU
iUi (10, 10, ff000000, 4, fc540200, 861908) + 14
003cef8c create__Q2t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0_3Re
pUi (2, 2, 2b10d5c8, fcbb5434, fcbb5784, fffc00) + 24
003ee944 replace__t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0UiUiP
CcUi (fc3efaf8, 0, ffffffff, 8618a0, 2, 80808080) + 114
006919cc assign__t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0PCcUi
(fc3efaf8, 8618a0, 2, 0, fc540200, 7164b4) + 24
00666684 assign__t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0PCc (f
c3efaf8, 8618a0, 8ea400, 0, fc5706c0, 0) + 24
005f7868 __t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0PCc (fc3efaf
8, 8618a0, 861800, 0, fc3efa90, a4090) + 28
....
----------------- lwp# 3 / thread# 3 --------------------
fcb41818 mutex_lock_impl (fcbb3910, 0, 2dfc0030, fc3beee0, 6, 80808080) + 4
fcad640c malloc (6, 1, d9fd8, 6919cc, fcbb03a8, fcbba518) + 44
003c878c __builtin_vec_new (6, 3, 37, fc3bee38, ff32a888, 4) + 3c
005e16ec __9stringbufRCt12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0
i (fc3bee60, fc3bee58, 3, 0, 2b2ab6e8, 20) + 64
...
----------------- lwp# 4 / thread# 4 --------------------
fcb48ac4 __lwp_park (0, 0, fcbb74c4, 1c00, 0, 0) + 14
ff375244 sem_wait (1da56f48, 1da56c00, 1, 0, fc541200, 0) + 20
....
fcb48a20 _lwp_start (0, 0, 0, 0, 0, 0)