std::string Destructor Throwing Exception

[Scott Brady Drummonds]

Hi, all,

I've a fairly small piece of code that is causing me problems. I'm using
std::string and am building a string of several dozen characters using
several of std::string's functions: a blank constructor, operator=, and
operator+=. This sequence of function calls causes a crash either at the
call to operator+= or when the string object leaves scope (which must be the
result of the destructor). Specifically, my Windows-based system reports
that an exception was not caught in some heap management code. This crash
occurs only in some binaries, and specifically not the small one I created
to post here.

After a lot of investigation, I determined that its operator+= that is the
culprit. Through the addition of a call to reserve() I have been able to
avoid the unhandled exception and subsequent crash (both the operator+= and
destructor crashes). My first thought was that these dumbasses (the
providers of my STL library; the obvious people) have a bug in
string:perator+=. However, then I realized that I know far to little
about C++ to get all high-and-mighty and assume that a library provider gave
me a buggy version of the STL.

So, my question to the group is this: what kind of misuse of std::string,
using only operator=, and operator+= could cause exceptions to be raised in
operator+= or the destructor? What combination of these functions is
illegal according to the language specifications? What requirements are
incumbent upon the user in terms of memory management? It was my
understanding that the beauty of using std::string was that I shouldn't have
to worry about memory management. reserve() could be called to help out,
but no special consideration is required of the user to inform the object of
its intended size.

Have I misunderstood something here? Since my strings are all automatic
variables, managed on the stack, and no other function calls occur in
between the object's creation and the unhandled exception, I can eliminate
the possibility of some of *my* other code corrupting the string, right?

Scott

 

[Howard]

Hi, all,

I've a fairly small piece of code that is causing me problems. I'm using
std::string and am building a string of several dozen characters using
several of std::string's functions: a blank constructor, operator=, and
operator+=. This sequence of function calls causes a crash either at the
call to operator+= or when the string object leaves scope (which must be
the
result of the destructor). Specifically, my Windows-based system reports
that an exception was not caught in some heap management code. This crash
occurs only in some binaries, and specifically not the small one I created
to post here.

After a lot of investigation, I determined that its operator+= that is the
culprit. Through the addition of a call to reserve() I have been able to
avoid the unhandled exception and subsequent crash (both the operator+=
and
destructor crashes). My first thought was that these dumbasses (the
providers of my STL library; the obvious people) have a bug in
string:perator+=. However, then I realized that I know far to little
about C++ to get all high-and-mighty and assume that a library provider
gave
me a buggy version of the STL.

So, my question to the group is this: what kind of misuse of std::string,
using only operator=, and operator+= could cause exceptions to be raised
in
operator+= or the destructor? What combination of these functions is
illegal according to the language specifications? What requirements are
incumbent upon the user in terms of memory management? It was my
understanding that the beauty of using std::string was that I shouldn't
have
to worry about memory management. reserve() could be called to help out,
but no special consideration is required of the user to inform the object
of
its intended size.

Have I misunderstood something here? Since my strings are all automatic
variables, managed on the stack, and no other function calls occur in
between the object's creation and the unhandled exception, I can eliminate
the possibility of some of *my* other code corrupting the string, right?

Post the code you're having problems with. We'd just be guessing, given the
information you have here. (The statement that you use a "blank
constructor" is especially confusing. Whose constructor is "blank"? Are
you trying to inherit from std:string, or...?)

-Howard

 

[Victor Bazarov]

I've a fairly small piece of code that is causing me problems. I'm using
std::string and am building a string of several dozen characters using
several of std::string's functions: a blank constructor, operator=, and
operator+=. This sequence of function calls causes a crash either at the
call to operator+= or when the string object leaves scope (which must be the
result of the destructor). Specifically, my Windows-based system reports
that an exception was not caught in some heap management code. This crash
occurs only in some binaries, and specifically not the small one I created
to post here.

And were is that small one you created to post here? What stopped you?

[...] My first thought was that these dumbasses (the
providers of my STL library; the obvious people) have a bug in
string:perator+=. However, then I realized that I know far to little
about C++ to get all high-and-mighty and assume that a library provider gave
me a buggy version of the STL.

Actually, there have been some corrections Dinkumware posted on their site
for the Standard Library implementation they licensed to MS in 1996. You
should check them out. If you're using VC++ v6, that is. You can always
switch to a different implementation, like STLport, for example, and see
if the trouble goes away.

[...]
Have I misunderstood something here? Since my strings are all automatic
variables, managed on the stack, and no other function calls occur in
between the object's creation and the unhandled exception, I can eliminate
the possibility of some of *my* other code corrupting the string, right?

No, there is always a possibility of that. Post your code and we will
help you eliminate those from the list of suspects.

V

 

[Andrey Tarasevich]

...

The crash symptoms that you describe indicate that at some point the
integrity of the heap has been destroyed. It does not necessary happen
due to some error in 'std::string's compound assignment operator or
destructor. My guess is that most likely some portion of _your_ code
damaged the heap before (maybe, _long_ before) the moment when the
actual exception in 'std::string's methods took place (and the fact that
you can't reproduce the problem in a smaller piece of code indirectly
supports that guess). The fact that using 'std::string::reserve' seems
to help doesn't really mean anything, since problems like this are very
easy to shoo away by almost any change in heap-related code. They will
re-appear later in some other completely unrelated place, like
'std::vector's destructor, for example.