«

I have the following line of code:

if (MyData)
{
delete MyData;
MyData= NULL;
}

Below is MyData:
SomeDataStructure *MyData;

Every time this code segment is called I get a fatal error that causes my
program to terminate.

I use the debugger and upon reaching this line of code MyData is still valid
and still has the correct information in it.
I have searched the internet and pretty much figured that it was some sort
of memory allocation problem... either I'm deleting what's not there, or
even I've read deleting from different stacks? Any ideas as to why this
delete cause and error?

* Venn Syii:
> I have the following line of code:
>
> if (MyData)
> {
> delete MyData;
> MyData= NULL;
> }

It suffices to write


delete MyData;


>
> Below is MyData:
> SomeDataStructure *MyData;
>
> Every time this code segment is called I get a fatal error that causes my
> program to terminate.
>
> I use the debugger and upon reaching this line of code MyData is still valid

*Seems* to be valid.

> and still has the correct information in it.

Any area of memory contains what it did earlier unless it has been
changed...


> Any ideas as to why this delete cause and error?

Technically:

* Your pointer MyData might be invalid, i.e. already deleted.

* The object's destructor might reference invalid data or divide
by zero or whatever.

* The process might be in an invalid state (stack, memory manager,
whatever) due to earlier errors.

Design-wise:

* You're using raw pointers instead of containers and smart-pointers.

* You haven't ensured the class invariant through all operations.

* You don't have a class invariant.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Venn Syii wrote:
> I have the following line of code:
>
> if (MyData)
> {
> delete MyData;
> MyData= NULL;
> }
>
> Below is MyData:
> SomeDataStructure *MyData;
>
> Every time this code segment is called I get a fatal error that causes my
> program to terminate.
>
> I use the debugger and upon reaching this line of code MyData is still valid
> and still has the correct information in it.

How do you know it's "valid"? On what do you base your conclusion of
its validity?

> I have searched the internet and pretty much figured that it was some sort
> of memory allocation problem... either I'm deleting what's not there, or
> even I've read deleting from different stacks? Any ideas as to why this
> delete cause and error?

The most common mistake leading to such error is deleting the memory
twice. After the first deletion the memory may still be OK (not reclaimed
by the OS) which can be misinterpreted that the pointer is still valid.

Another mistake, less common, is not allocating the memory in the first
place but using an address of a static or automatic object. Since the
memory wasn't allocated using 'new', it shouldn't be freed using 'delete'.

Read FAQ 5.8.

V

Alf P. Steinbach wrote:
> * Venn Syii:
>
>>I have the following line of code:
>>
>> if (MyData)
>> {
>> delete MyData;
>> MyData= NULL;
>> }
>
>
> It suffices to write
>
>
> delete MyData;

No, it does not. Setting a pointer to NULL after deletion prevents any
further double deletions of the same memory.

> [...]

V

Venn Syii wrote:

>I have the following line of code:
>
> if (MyData)
> {
> delete MyData;
> MyData= NULL;
> }
>
>Below is MyData:
>SomeDataStructure *MyData;
>
>Every time this code segment is called I get a fatal error that causes my
>program to terminate.
>
>I use the debugger and upon reaching this line of code MyData is still valid
>and still has the correct information in it.
>I have searched the internet and pretty much figured that it was some sort
>of memory allocation problem... either I'm deleting what's not there, or
>even I've read deleting from different stacks? Any ideas as to why this
>delete cause and error?
>
>
>
Looks like a memory access error. Why don't you run purify/valgrind ?

Krishanu

Thanks for your fast answer. I've tracked it through the destructor and it
get's through that fine. It's right after that it goes bad. I'm assuming
more then likely it's option:
1) Your pointer MyData might be invalid, i.e. already deleted.
in conjunction with
2)*Seems* to be valid.

I'll dig through the code more to see.
"Alf P. Steinbach" <> wrote in message
news:...
>* Venn Syii:
>> I have the following line of code:
>>
>> if (MyData)
>> {
>> delete MyData;
>> MyData= NULL;
>> }
>
> It suffices to write
>
>
> delete MyData;
>
>
>>
>> Below is MyData:
>> SomeDataStructure *MyData;
>>
>> Every time this code segment is called I get a fatal error that causes my
>> program to terminate.
>>
>> I use the debugger and upon reaching this line of code MyData is still
>> valid
>
> *Seems* to be valid.
>
>> and still has the correct information in it.
>
> Any area of memory contains what it did earlier unless it has been
> changed...
>
>
>> Any ideas as to why this delete cause and error?
>
> Technically:
>
> * Your pointer MyData might be invalid, i.e. already deleted.
>
> * The object's destructor might reference invalid data or divide
> by zero or whatever.
>
> * The process might be in an invalid state (stack, memory manager,
> whatever) due to earlier errors.
>
> Design-wise:
>
> * You're using raw pointers instead of containers and smart-pointers.
>
> * You haven't ensured the class invariant through all operations.
>
> * You don't have a class invariant.
>
> --
> A: Because it messes up the order in which people normally read text.
> Q: Why is it such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing on usenet and in e-mail?

* Victor Bazarov:
> Alf P. Steinbach wrote:
> > * Venn Syii:
> >
> >>I have the following line of code:
> >>
> >> if (MyData)
> >> {
> >> delete MyData;
> >> MyData= NULL;
> >> }
> >
> >
> > It suffices to write
> >
> >
> > delete MyData;
>
> No, it does not. Setting a pointer to NULL after deletion prevents any
> further double deletions of the same memory.

Well, we could argue about that.

I've taken both sides (not simultanously, of course!) over the years.

Currently, my thinking is that _if_ setting it to NULL prevents a double
deletion, _then_ setting it to NULL most probably prevents detection of
a serious bug.

However, there can be other more valid reasons for setting a pointer to
NULL after deletion, e.g. for optimization purposes. For example,
deletions are rare, and this pointer is in the middle of an array of
pointers; MyData above would then be a reference to that array element.
Given the OP's definition of MyData I don't think that's the case here.

In short, I disagree.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Heh... now I really feel newbie... what's purify/valgrind?


----- Original Message -----
From: "Krishanu Debnath" <>
Newsgroups: comp.lang.c++
Sent: Thursday, December 02, 2004 10:07 AM
Subject: Re: Delete Problem


> Venn Syii wrote:
>
>>I have the following line of code:
>>
>> if (MyData)
>> {
>> delete MyData;
>> MyData= NULL;
>> }
>>
>>Below is MyData:
>>SomeDataStructure *MyData;
>>
>>Every time this code segment is called I get a fatal error that causes my
>>program to terminate.
>>
>>I use the debugger and upon reaching this line of code MyData is still
>>valid
>>and still has the correct information in it.
>>I have searched the internet and pretty much figured that it was some sort
>>of memory allocation problem... either I'm deleting what's not there, or
>>even I've read deleting from different stacks? Any ideas as to why this
>>delete cause and error?
>>
>>
>>
> Looks like a memory access error. Why don't you run purify/valgrind ?
>
> Krishanu
>
>

Alf P. Steinbach wrote:
> [...]
> In short, I disagree.

Why am I not surprised?...

"Venn Syii" <> wrote in message
news:SNGrd.78610$...
> I have the following line of code:
>
> if (MyData)
> {
> delete MyData;

What was used to allocate memory for 'MyData'? If it
was 'new[]' (not 'new'), then you need to write

delete[] MyData;


-Mike