Calling delete Crashes my Program

I'm am trying to write a little program/algorithm in C++. I have defined my own data type and created an array of this data type using the new operator. I try to return this memory to the system by using the delete operator on my array, but it seems to crash my program. The program compiles okay, but when I run it, I get the message

Quote:

---

2 [sig] a 2216 open_stackdumpfile: Dumping stack trace to a.exe.stackdump
14277 [sig] a 2216 e:\working\a.exe: *** fatal error - called with threadlist_ix -1

---

If I don't use the delete operator then the program runs without crashing. The problem with this, is that I'm under the impression that every new should be matched with a delete. Does anyone know why my program is crashing?

If you use new, use delete.
If you use new[], use delete[].

Without seeing the code, it's almost impossible to say what is going wrong, but "it ain't right" when delete causes your app to crash - and it wouldn't be delete's fault.

Two things come to mind:
1. You are overflowing some allocated memory and overwriting some data kept after the memory you allocated.
2. (Less likely, but possible) you are using new something[...] and not using delete [] ... - if you have square brackets when allocating, you need square brackets on deleting - and the same applies if you DON'T have square brackets in one place, you shouldn't have them in the other.

--
Mats

u must be pointing to any non allocated memory...using signal(), that will help:)...

Another common cause of a crash on delete is, unfortunately, a pointer molestation somewhere before deleting. I say "unfortunately" because the problem could be ANY of your code that was executed before you attempt to delete your array.

On of the rules of debugging is that the cause of a crash (i.e. abnormal program termination) is either at the crash site, or it is any code executed BEFORE the crash occurs. Ironically, one of the common mistakes of newbies is to try and find the cause of a crash by stepping FORWARD, in a debugger, from the crash.

The data type has a destructor that calls delete[]. When I remove this, then the program runs. I don't know if this is useful information or not.

So, assuming that you are also using new ... [] then that's the right version of delete.

The most likely scenario is that you have written past the end of your allocated memory, e.g. :

Code:

---

  int *p = new int[10];
  ...
  p[11] = 7;

---

This will cause undefned behaviour, which can be "anything", but the most likely scenario is a "crash" of some sort.

Again, without seeing the code, it's almost impossible to even guess what the actual problem is.

Try checking all your limits where you are writing to arrays.

--
Mats

Quote:

---

Originally Posted by thetinman

The data type has a destructor that calls delete[]. When I remove this, then the program runs. I don't know if this is useful information or not.

---

So assuming you are using new[] and delete[] together, the crash is caused by corruption of the allocator's free list, which means you overflowed a dynamic array somewhere. The problem is not necessarily with the array you are trying to delete[], but you can at least start there.

Examine all parts of your code where you index arrays, particularly code which writes into them. Look for bounds violations.

Or, compile your program on Linux and run it under Valgrind, which will immediately pinpoint the exact bug.

>> The data type has a destructor that calls delete[].
Does this class have a copy constructor and copy assignment operator. If you use delete[] in your destructor you will need to either disable copying or implement those two functions. If you don't, your program will crash when you call delete[] in some cases.

Why are you using new[] and delete[] anyway? You should probably be using vector. If you did, you wouldn't need the code in your destructor, and that wouldn't force you to write the copy functions either.

Quote:

---

Originally Posted by Daved

Why are you using new[] and delete[] anyway? You should probably be using vector. If you did, you wouldn't need the code in your destructor, and that wouldn't force you to write the copy functions either.

---

Or at least use boost::scoped_array<>, which auto-deletes the array and is also non-copyable, which prevents you from accidentally writing a class which aliases the array.

Quote:

---

Originally Posted by Daved

>> The data type has a destructor that calls delete[].
Does this class have a copy constructor and copy assignment operator. If you use delete[] in your destructor you will need to either disable copying or implement those two functions. If you don't, your program will crash when you call delete[] in some cases.

Why are you using new[] and delete[] anyway? You should probably be using vector. If you did, you wouldn't need the code in your destructor, and that wouldn't force you to write the copy functions either.

---

The force is strong in this one.

I am always using new[] and delete[] together. As far as I know, everything is in bounds.

None of my classes have copy constructors or copy assignment operators. It isn't clear to me that I need these. Maybe I do, since one data type is copied into a member variable (that is the same type as the input) of a different data type.

I am using new[] and delete[] because vector does not seem to allow me to access elements of arrays arbitrarily. I consider this to be a big drawback.

Quote:

---

Originally Posted by thetinman

None of my classes have copy constructors or copy assignment operators.

---

More likely, ALL your classes have copy constructors and assignment operators. If you don't write them, the compiler synthesizes them. If you want to prevent copy construction or assignment, you have to do it explicitly.

Quote:

---

I am using new[] and delete[] because vector does not seem to allow me to access elements of arrays arbitrarily. I consider this to be a big drawback.

---

Huh? That's the whole point of vector. Just use [].

>> It isn't clear to me that I need these.
If you have delete[] in your destructor, then you absolutely need those. That is almost certainly why your program crashes.

>> I am using new[] and delete[] because vector does not seem to allow me to access elements of arrays arbitrarily.
I can't think of anything that a dynamic array with new[]/delete[] can do that vector cannot do, and there are a pile of things that vector can do better.

Quote:

---

Originally Posted by thetinman

I am always using new[] and delete[] together. As far as I know, everything is in bounds.

None of my classes have copy constructors or copy assignment operators. It isn't clear to me that I need these. Maybe I do, since one data type is copied into a member variable (that is the same type as the input) of a different data type.

I am using new[] and delete[] because vector does not seem to allow me to access elements of arrays arbitrarily. I consider this to be a big drawback.

---

Sure you can:
vector::operator[]

--
Mats

Quote:

---

Originally Posted by matsp

Sure you can:
vector::operator[]

--
Mats

---

God I hate that auto-smiley thing.

Me too. I just edited the post to "disable smilies".

--
Mats

Can't you just try to put out the contents of your array right before the deletion? And If you get just garbage when move back that output in the execution path until you identified the place that corrupts you memory or pointers.

Quote:

---

Originally Posted by grumpy

Ironically, one of the common mistakes of newbies is to try and find the cause of a crash by stepping FORWARD, in a debugger, from the crash.

---

How can I step forward from a crash on (any crash I've seen so far had the surprising side effect of process termination)?

Quote:

---

Originally Posted by pheres

How can I step forward from a crash on (any crash I've seen so far had the surprising side effect of process termination)?

---

Depends on your debugger; several available debuggers return control to the user when an error condition is encountered within the program. And a lot of users insist on then stepping forward, in the debugger, from that point.

Ah, ok. Gdb, the debugger I'm using most of the time, doesn't seem to do that. That exactly is the sense of "returning control" in the moment the process is terminated by the OS?