STL string segfault

[Vedran Vyroubal]

Hi all!
I have a problem with STL string.
My program segfaults after a period of time, it can run perfectly for
days and than die after a week, and when it segfaults it doesn't have to
be at the same place. This is a backtrace:

Program received signal SIGSEGV, Segmentation fault.
[Switching to thread 580.0x7b0]
0x00485f66 in std::__default_alloc_template<true, 0>::allocate(unsigned) ()
(gdb) bt
#0 0x00485f66 in std::__default_alloc_template<true,
0>::allocate(unsigned) ()
#1 0x0047e0ec in std::string::_Rep::_S_create(unsigned,
std::allocator<char> const&) ()
#2 0x0047dfed in std::string::_Rep::_M_clone(std::allocator<char>
const&, unsigned) ()
#3 0x0047f4d1 in std::string::reserve(unsigned) ()
#4 0x0047e5f5 in std::string::append(unsigned, char) ()
#5 0x004801c2 in std::string:perator+=(char) ()
#6 0x00415fdd in T10::enable_delivery() ()
#7 0x004133f7 in T10:rocess_status() ()
#8 0x0040bd80 in T10:rocess_command(char*, char*) ()
#9 0x0040688e in PSS::z3(int) ()
#10 0x00405eee in PSS::switch_states(int) ()
#11 0x00404cba in PSS:ss_cruncher(std::string&) ()
#12 0x0041ba83 in V11_2::s9() ()
#13 0x0041a773 in V11_2::runner() ()
#14 0x0041a68b in V11_2::v11_starter(int) ()

This is just an example how it dies, but bt is always the same from
"std::string:perator+=(char) ()" upwards!
Threading is minimal and critical sections are used, OS is Win2K and
compiler is mingw (gcc version 3.2.3 (mingw special 20030504-1)).

Help!

 

[John Harrison]

Hi all!
I have a problem with STL string.
My program segfaults after a period of time, it can run perfectly for
days and than die after a week, and when it segfaults it doesn't have to
be at the same place. This is a backtrace:

Program received signal SIGSEGV, Segmentation fault.
[Switching to thread 580.0x7b0]
0x00485f66 in std::__default_alloc_template<true, 0>::allocate(unsigned) ()
(gdb) bt
#0 0x00485f66 in std::__default_alloc_template<true,
0>::allocate(unsigned) ()
#1 0x0047e0ec in std::string::_Rep::_S_create(unsigned,
std::allocator<char> const&) ()
#2 0x0047dfed in std::string::_Rep::_M_clone(std::allocator<char>
const&, unsigned) ()
#3 0x0047f4d1 in std::string::reserve(unsigned) ()
#4 0x0047e5f5 in std::string::append(unsigned, char) ()
#5 0x004801c2 in std::string:perator+=(char) ()
#6 0x00415fdd in T10::enable_delivery() ()
#7 0x004133f7 in T10:rocess_status() ()
#8 0x0040bd80 in T10:rocess_command(char*, char*) ()
#9 0x0040688e in PSS::z3(int) ()
#10 0x00405eee in PSS::switch_states(int) ()
#11 0x00404cba in PSS:ss_cruncher(std::string&) ()
#12 0x0041ba83 in V11_2::s9() ()
#13 0x0041a773 in V11_2::runner() ()
#14 0x0041a68b in V11_2::v11_starter(int) ()

This is just an example how it dies, but bt is always the same from
"std::string:perator+=(char) ()" upwards!
Threading is minimal and critical sections are used, OS is Win2K and
compiler is mingw (gcc version 3.2.3 (mingw special 20030504-1)).

Help!

It's simple enough to diagnose, but complex to fix. You have heap
corruption, there is no way that string operator+= should fail except if the
heap is corrupt. But the problem is what is causing the heap corruption?
There is no reason that it should be your string handling, it could easily
be something completely different in your program. Pointers and fixed size
arrays are the usual culprits but really it could be anything.

john

 

[Vedran Vyroubal]

It's simple enough to diagnose, but complex to fix. You have heap

corruption, there is no way that string operator+= should fail except if the
heap is corrupt. But the problem is what is causing the heap corruption?
There is no reason that it should be your string handling, it could easily
be something completely different in your program. Pointers and fixed size
arrays are the usual culprits but really it could be anything.

john

I was afraid of that! Thanks anyway!

 

[Sharad Kala]

I was afraid of that! Thanks anyway!

I think using a tool like Rational Purify can certainly help here.

 

[visage]

Hi all!
I have a problem with STL string.
My program segfaults after a period of time, it can run perfectly for
days and than die after a week, and when it segfaults it doesn't have to
be at the same place. This is a backtrace:

Program received signal SIGSEGV, Segmentation fault.
[Switching to thread 580.0x7b0]
0x00485f66 in std::__default_alloc_template<true, 0>::allocate(unsigned) ()
(gdb) bt
#0 0x00485f66 in std::__default_alloc_template<true,
0>::allocate(unsigned) ()
#1 0x0047e0ec in std::string::_Rep::_S_create(unsigned,
std::allocator<char> const&) ()
#2 0x0047dfed in std::string::_Rep::_M_clone(std::allocator<char>
const&, unsigned) ()
#3 0x0047f4d1 in std::string::reserve(unsigned) ()
#4 0x0047e5f5 in std::string::append(unsigned, char) ()
#5 0x004801c2 in std::string:perator+=(char) ()
#6 0x00415fdd in T10::enable_delivery() ()
#7 0x004133f7 in T10:rocess_status() ()
#8 0x0040bd80 in T10:rocess_command(char*, char*) ()
#9 0x0040688e in PSS::z3(int) ()
#10 0x00405eee in PSS::switch_states(int) ()
#11 0x00404cba in PSS:ss_cruncher(std::string&) ()
#12 0x0041ba83 in V11_2::s9() ()
#13 0x0041a773 in V11_2::runner() ()
#14 0x0041a68b in V11_2::v11_starter(int) ()

This is just an example how it dies, but bt is always the same from
"std::string:perator+=(char) ()" upwards!
Threading is minimal and critical sections are used, OS is Win2K and
compiler is mingw (gcc version 3.2.3 (mingw special 20030504-1)).

Help!

Hard to tell without more code, but, given that something's going
wrong in an allocate() method, that kinda points to a problem running
out of memory. This hypothesis is supported by the fact that your
program takes varying amounts of time to fail...Have you looked at how
the program's memory usage varies over time?

 

[Vedran Vyroubal]

Hard to tell without more code, but, given that something's going
wrong in an allocate() method, that kinda points to a problem running
out of memory. This hypothesis is supported by the fact that your
program takes varying amounts of time to fail...Have you looked at how
the program's memory usage varies over time?

That's just the thing, mem usage is more or less fixed over time.
Just to clarify more, this program controls a piece of hardware over
RS-232 line, and the only place where memory varies is message queue I
use, and I have checked this code over a million times already!
The source of my frustration is that the code runs on two boxes, and the
curious thing is that it dies a lot faster on the newer and faster box
with 256 megs and 2 gig processor, while on the older one with 128 megs
and 300 MHz processor on average it runs for a week. Go figure!