By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,131 Members | 2,055 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,131 IT Pros & Developers. It's quick & easy.

Segmentation fault / string allocator question

P: n/a
I have a segmentation fault, and gdb says that the problem is in the
line:

buffer+=(s+' ');

inside the + operator. "buffer" and "s" are both C++ strings. When I
print out
buffer.c_str() and s.c_str() in gdb, I get ordinary strings ... no
null pointers are evident.
The line runs just fine many times in a row, and then mysteriously
fails.
I have pasted in the backtrace from gdb below, up to the point where
it reaches the + operator.

Is it possible that the program is just running out of memory? And if
so, how would I test that? Any other ideas as to what could cause
this? Is there any other useful information I should provide? Thanks
-

#0 std::__default_alloc_template<true, 0>::allocate (__n=41)
at /usr2/SOURCES/S9/gcc-3.3.2/objdir/sparc-sun-solaris2.9/libstdc+
+-v3/include/bits/stl_alloc.h:417
#1 0xff15ab8c in std::string::_Rep::_S_create (__capacity=21,
__alloc=@0xffbbd428)
at /usr2/SOURCES/S9/gcc-3.3.2/objdir/sparc-sun-solaris2.9/libstdc+
+-v3/include/bits/stl_alloc.h:673
#2 0xff15ac84 in std::string::_Rep::_M_clone (this=0x25b6b0,
__alloc=@0xffbbd428, __res=1)
at /usr2/SOURCES/S9/gcc-3.3.2/objdir/sparc-sun-solaris2.9/libstdc+
+-v3/include/bits/basic_string.tcc:582
#3 0xff158fdc in std::string::reserve (this=0xffbbd5b8,
__res=4290499624)
at /usr2/SOURCES/S9/gcc-3.3.2/objdir/sparc-sun-solaris2.9/libstdc+
+-v3/include/bits/basic_string.h:408
#4 0xff1593f4 in std::string::append (this=0xffbbd5b8, __n=1, __c=32
' ')
at /usr2/SOURCES/S9/gcc-3.3.2/objdir/sparc-sun-solaris2.9/libstdc+
+-v3/include/bits/basic_string.tcc:718
#5 0x000ba8b8 in std::operator+<char, std::char_traits<char>,
std::allocator<char (__lhs=@0xffbbd5e0, __rhs=32 ' ')

Feb 21 '07 #1
Share this Question
Share on Google+
2 Replies


P: n/a
* Josh:
I have a segmentation fault, and gdb says that the problem is in the
line:

buffer+=(s+' ');

inside the + operator. "buffer" and "s" are both C++ strings. When I
print out
buffer.c_str() and s.c_str() in gdb, I get ordinary strings ... no
null pointers are evident.
Post a complete small program that exhibits the problem.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Feb 21 '07 #2

P: n/a
Josh wrote:
I have a segmentation fault, and gdb says that the problem is in the
line:

buffer+=(s+' ');

inside the + operator. "buffer" and "s" are both C++ strings. When I
print out
buffer.c_str() and s.c_str() in gdb, I get ordinary strings ... no
null pointers are evident.
The line runs just fine many times in a row, and then mysteriously
fails.
I have pasted in the backtrace from gdb below, up to the point where
it reaches the + operator.

Is it possible that the program is just running out of memory? And if
so, how would I test that? Any other ideas as to what could cause
this? Is there any other useful information I should provide? Thanks
-
Your problem sounds like a classic case of memory corruption.

That's the problem with memory corruption, the crash happens sometime
after the corruption happens. This makes the bug hard to track down.

The answer is to avoid dubious coding styles in the first place, but
that's not likely to be much help to you now. If you can't figure out
wher the bug is then the answer is to methodically reduce the size of
your code. It doesn't matter if the code no longer does anything
sensible, as long as it still compiles and runs. At some point as you
are making your code smaller and smaller the bug will mysteriously go
away. When that happens the last piece of code you removed will likely
be the cause of the memory corruption. When this happens you will be in
a much better position to understand precisely what the problem was, you
will also be a better programmer, having learned a valuable lesson.

john
Feb 21 '07 #3

This discussion thread is closed

Replies have been disabled for this discussion.