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
