If you need to track down a bug where memory is being corrupted,
there is a useful tool called valgrind. If you write outside the
bounds of an array, it is possible that you overwrite the memory
needed for the delete operation.

Typically the size of the array is stored in memory just before
the array, call this array A. Now suppose array B is stored
in memory just before array A. If you write outside of B, you
may overwrite where the size is stored for A. Then, when you
try to delete the array A, you crash.

The error shows itself to you as the destructor or delete, but it is
not the problem. It could be any routine and can be hard to track down.

On the linux machines, valgrind is a memory checker (there is a
link to its home page on our website). To use valgrind, after
you compile, enter:  valgrind ./a.out

This will execute your program, give output, as well as run it
through valgrind. Here is a simple program that both reads and
writes outside the bounds of the array, and has a memory leak:

int main() {
   int* p = new int[5];    // memory leak, never deleted
   p[6] = 100;             // invalid write
   p[2] = p[6];            // invalid read
   return 0;
}

Here is the output from valgrind with commentary by me:

Memcheck, a memory error detector
Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
Command: ./a.out

Invalid write of size 4
   at 0x4005B6: main (in /nfs/aesop02/rc00/d55/zander/css342/a.out)
 Address 0x590e058 is 4 bytes after a block of size 20 alloc'd
   at 0x4C212CA: operator new[](unsigned long) (vg_replace_malloc.c:264)
   by 0x4005A9: main (in /nfs/aesop02/rc00/d55/zander/css342/a.out)

***** Commentary -- what is useful here is knowing that the invalid 
***** write is in main. Ignore the detailed information. This tells
***** you that it is here that you are writing outside of your array.

Invalid read of size 4
   at 0x4005CC: main (in /nfs/aesop02/rc00/d55/zander/css342/a.out)
 Address 0x590e058 is 4 bytes after a block of size 20 alloc'd
   at 0x4C212CA: operator new[](unsigned long) (vg_replace_malloc.c:264)
   by 0x4005A9: main (in /nfs/aesop02/rc00/d55/zander/css342/a.out)

***** Commentary -- same as before, what is useful here is knowing 
***** that the invalid read is in main. Ignore the detailed information.

HEAP SUMMARY:
    in use at exit: 20 bytes in 1 blocks
  total heap usage: 1 allocs, 0 frees, 20 bytes allocated

LEAK SUMMARY:
   definitely lost: 20 bytes in 1 blocks
   indirectly lost: 0 bytes in 0 blocks
     possibly lost: 0 bytes in 0 blocks
   still reachable: 0 bytes in 0 blocks
        suppressed: 0 bytes in 0 blocks
Rerun with --leak-check=full to see details of leaked memory

For counts of detected and suppressed errors, rerun with: -v
ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 4 from 4)

***** Commentary -- you can see there is a memory leak because 
***** 20 bytes are definitely lost.
***** For the details, enter:  valgrind --leak-check=full ./a.out