Source(s) of St9bad_alloc exception

[Jeff Holle]

I would like to thank Eljay for this informative answer, but must point 
out a somewhat time consuming error that it has, at least for the gcc 
v3.3 compiler in debug mode.

It is not a no-op to pass a NULL pointer to delete. It caused a segment 
dump on my system, whose source I needed a good debugger to find.

Happily I discovered ddd in the process.
http://www.gnu.org/software/ddd/

Eljay Love-Jensen wrote:

>Hi Jeff,
>
>  
>
>>What are the possible sources of this error.  I assume new, but can it be produced by giving delete a bogus pointer?
>>    
>>
>
>When new fails to allocate the memory for an object, or new[] fails to allocate the memory for an object array, a std::bad_alloc object is thrown.  In GCC, the RTTI mangled name of std::bad_alloc is, I'm guessing, St9bad_alloc.
>
>Giving delete a bogus pointer, or delete[] a bogus pointer, or giving delete a "delete[]" (array) pointer, or delete[] a "delete" (non-array, single object) pointer will not cause this problem.  What it would do is (probably) cause your application's memory heap to become corrupted, and your program to up-n-die with a bug-in-waiting.  But it may not necessarily die at the delete or delete[] ... it could run for quite some time before SEGV.
>
>Note:  it is legit (not bogus) to give delete and delete[] a NULL pointer.  That's a no-op.
>
>There are third-party heap managers that detect and report delete / delete[] on a bogus pointer.  They aren't used for run-time, because they tend to be significantly slower (a lot more overhead to maintain all the "paranoia" bookkeeping details).
>
>There are also other tools (like valgrind and electric fence) to detect several categories of pointer problems.
>
>  
>
>>Is there a more informative method to use, perhaps in a class deriving from exception?
>>    
>>
>
>You could set a breakpoint in gdb on the... if I recall correctly... __throw routine, and that will enable you to backtrace the stack and see culprit.
>
>HTH,
>--Eljay
>
>
>
>  
>