Hello,
We've had a SIGSEGV occuring in std::string append call during a
stress test of a software, after it ran for two days without any
problem :
here's the backtrace :
[...] Above is our signal handler
#8 0x080506b7 in signal_handler (sigNum=11) at main.cpp:154
#9 0x4035b825 in __pthread_sighandler () from /lib/libpthread.so.0
#10 <signal handler called>
#11 0x40447642 in std::__default_alloc_template<true, 0>::allocate ()
from /usr/lib/libstdc++.so.5
#12 0x4044d008 in std::string::_Rep::_S_create () from /usr/lib/libstdc++.so.5
#13 0x40449c80 in std::string::_M_mutate () from /usr/lib/libstdc++.so.5
#14 0x4044d8ea in
std::string::_M_replace_safe<__gnu_cxx::__normal_iterator<char*,
std::string> > () from /usr/lib/libstdc++.so.5
#15 0x4044b04d in std::string::append () from /usr/lib/libstdc++.so.5
#16 0x08050d1f in std::operator+<char, std::char_traits<char>,
std::allocator<char> > (__lhs=@0xb75ff544, __rhs=@0x410a4c90)
at basic_string.h:871
[...] below if the concatenation called
And here's what gdb can tell us :
(gdb) frame 16
#16 0x08050d1f in std::operator+<char, std::char_traits<char>,
std::allocator<char> > (__lhs=@0xb75ff544, __rhs=@0x410a4c90)
at basic_string.h:871
871 __str.append(__rhs);
(gdb) p __rhs
$13 = (const std::string &) @0x410a4c90: {static npos = 4294967295,
_M_dataplus = {<std::allocator<char>> = {<No data fields>},
_M_p = 0x8077bb4 ""}, static _S_empty_rep_storage = {0, 0, 2311, 0}}
(gdb) p __str
$14 = {static npos = 4294967295, _M_dataplus = {<std::allocator<char>>
= {<No data fields>},
_M_p = 0x40f19a14 "NoSuchElementException:("}, static
_S_empty_rep_storage = {0, 0, 2311, 0}}
The line of code where the SIGSEGV occurs is :
mFullReason = mName + ":(" + mReason + ")";
with mName being "NoSuchElementException" and mReason being ""
And we can see in the append that it SIGSEGVs while trying to append "
NoSuchElementException:(" and "" Which isn't exactly the result
expected :)
As this only happened during a stress test and it worked without any
problem for two days straight I was thinking this might be an issue on
the libstdc++ side.
Anyone has seen a similar problem ?
Version used is g++ (GCC) 3.3.5 (Debian 1:3.3.5-13) on a "Intel(R)
Pentium(R) 4 CPU 2.66GHz" single processor.
Best regards,
Guillaume
