gt; 1. str is just a local variable, the exception occur in the ~std::string()
Because frequently it may be damaged but for a while the heap may appear to
do its job.
But with a damaged heap, various allocations/deallocations may well damage
Eventually the point comes where the damage is so severe that an illegal
read/write occurs which is trapped by the processor, the OS catches the
exceptions generated and the plug is pulled on your program.
It is rather like shooting someone in the leg.
For a while they might be able to walk.
But if they continue to bleed eventually they will die.
There is nothing wrong with string.
And in all likelyhood there is nothing wrong with your use of it.
But string, vector, deque, list, map, new, malloc(), even fread() all get
memory ultimately from the heap.
And if you have damaged the heap, then they are all potentially affected.
You need to examine your code.
In particular the lines before string's destructor.
Was this in a free function or member function?
From a previous message here:
Heap corruption can occur with
1. Overwriting memory after the last valid byte obtained from
2. Underwriting memory before the first valid byte obtained from
new/malloc()/calloc()/realloc( (this is quite rare)
3a. Calling delete on memory obtained by new/malloc()/calloc()/reallo()
3b. Calling delete  on memory obtained by new/malloc()/calloc()/realloc(
3c. Calling free() on memory obtained by new/new
On the last three points, new should always be paired with delete, new
with delete and malloc()/calloc()/realloc() with free(). A gross error to
4. Calling free(),delete, delete more than once on a non-NULL pointer. A
5. Calling free(),delete, delete on pointers not obtained from
malloc()/calloc()/realloc(), new or new respectively. A gross error.
6. Read/Writing to what was once valid memory obtained from
new/new/malloc()/calloc()/relloc() but has since been returned to the
heap via delete/delete/free().
7. Passing to realloc() a non-NULL pointer not obtained from a previous call
7. Forgetting that realloc() may return a pointer different from the one
8. Reusing the old pointer passed to realloc()
9. Forgetting to write a class-specific operator delete if you have written
a class-specific operator new>>>>>>>>>>>>>>>>>>>>>>>
4 is the one that will gurantee to corrupt the heap as
delete/delete/free() of the 1st passed pointer if this results in adjacent
free block merging.
Also, if you have a class which contains pointers to new'ed memory which you
deallocate in the destructor, then you need to think about the copy
constructor and assignment operator.
The compiler-generated versions will be wrong.
This is sometimes known as the law-of-the-big-3:
If it is essential your class has a user-defined destructor, then the
chances are you need user-defined copy constructor and assignment operator.
If you need 1, you need all 3.
Failure to consider this can lead to heap corruption.