Possible causes for the 'delete ptr;' to core??

[qazmlp1209]

My program cores at the 'delete ptr;' statement.
I could think of the following possibilities for the core/undefined
behaviour:
- delete twice
- new/malloc is done, but subsequently free/delete is used.
- 'new' is done; Pointer reference is changed; 'delete' is done;

What else can be the reason?

 

[Ivan Novick]

My program cores at the 'delete ptr;' statement.
I could think of the following possibilities for the core/undefined
behaviour:
- delete twice
- new/malloc is done, but subsequently free/delete is used.
- 'new' is done; Pointer reference is changed; 'delete' is done;

What else can be the reason?

You can find the reason your self by running your program with a memory
checker... for example this one http://www.valgrind.org

 

[Jacek Dziedzic]

My program cores at the 'delete ptr;' statement.
I could think of the following possibilities for the core/undefined
behaviour:
- delete twice
- new/malloc is done, but subsequently free/delete is used.
- 'new' is done; Pointer reference is changed; 'delete' is done;

What else can be the reason?

Using delete on a pointer not obtained from new, eg.
- from malloc,
- from new[],
- from somewhere else (that boils down to your case 3).

Or, if ptr points to an instance of the class, perhaps
the destructor is to blame.

As Ivan pointed out, if you are on a x86, you may try
valgrind to pinpoint the problem easily.

HTH,
- J.

 

[Sylvester Hesp]

My program cores at the 'delete ptr;' statement.
I could think of the following possibilities for the core/undefined
behaviour:
- delete twice
- new/malloc is done, but subsequently free/delete is used.
- 'new' is done; Pointer reference is changed; 'delete' is done;

What else can be the reason?

Another reason might be writing before or beyond the memory buffer ptr
points to (thus overwriting heap management data)

- Sylvester

 

[Ron Natalie]

My program cores at the 'delete ptr;' statement.
I could think of the following possibilities for the core/undefined
behaviour:
- delete twice
- new/malloc is done, but subsequently free/delete is used.
- 'new' is done; Pointer reference is changed; 'delete' is done;

What else can be the reason?

Another popular misbehavior is writing off the end of the
allocation, which corrupts the memory allocator:
i.e.,
char* x = new char[10];
strcpy(x, "abcdefghijklmnopqrstuvwxyz", 26);

 

[Sylvester Hesp]

My program cores at the 'delete ptr;' statement.
I could think of the following possibilities for the core/undefined
behaviour:
- delete twice
- new/malloc is done, but subsequently free/delete is used.
- 'new' is done; Pointer reference is changed; 'delete' is done;

What else can be the reason?

Another popular misbehavior is writing off the end of the
allocation, which corrupts the memory allocator:
i.e.,
char* x = new char[10];
strcpy(x, "abcdefghijklmnopqrstuvwxyz", 26);

Yes, or before the start, like I already said
In your example: x[-2] = 'a';
Granted, this happens less often, but is not less important

- Sylvester

 

[Noah Roberts]

My program cores at the 'delete ptr;' statement.
I could think of the following possibilities for the core/undefined
behaviour:
- delete twice
- new/malloc is done, but subsequently free/delete is used.
- 'new' is done; Pointer reference is changed; 'delete' is done;

What else can be the reason?

Another popular misbehavior is writing off the end of the
allocation, which corrupts the memory allocator:
i.e.,
char* x = new char[10];
strcpy(x, "abcdefghijklmnopqrstuvwxyz", 26);

Yes, or before the start, like I already said
In your example: x[-2] = 'a';
Granted, this happens less often, but is not less important

It is the more difficult to find for sure and can explode deep inside
libary objects like vector or string. There is often no relationship
at all between the object that got overwritten and the one that
explodes. This type of bug can take hours or days to track down even
with the right tools. VS has settings you can make that check for
overruns and there are debugging applications that will do the same.