Reusing a deleted pointer.

[Alan]

Using VC++ (1998) compiler with PFE32 editor in Win2K Pro SP4.
(DigitalMars CD on order. )

The program (below) instantiates a class and then deletes it.
I would have thought that reusing the deleted pointer would
have caused an exception, but it does not - or my coding or
thinking is incorrect?

#include <iostream>
using namespace std;

class A {
int a;
public:
A(): a(0) { cout << " A::A()" << endl; }
~A() { cout << "~A::A()" << endl << endl; }
void print() { cout << "a = " << a << endl; }
void set(const int& aa) { a=aa; print(); }
};

int main() {

A* b = new A; // ptr
A& c = *b; // ref

b->set(10); // test ptr
c.set(5); // test ref

delete b;

try {
A& y = *b; // no problems!
y.set(55); // causes system error (msg in Dos-box)
} catch(...) { cout << "failed" << endl; exit(-1); }

cout << "No failure" << endl; // always gets here

return 0;
}

 

[David Lindauer]

Using VC++ (1998) compiler with PFE32 editor in Win2K Pro SP4.
(DigitalMars CD on order. )

The program (below) instantiates a class and then deletes it.
I would have thought that reusing the deleted pointer would
have caused an exception, but it does not - or my coding or
thinking is incorrect?

reusing a deleted pointer (or really any invalid pointer) simply causes
'undefined behavior'. Now undefined behaviour 'could' result in an
exception, the same way it 'could' result in your computer taking a trip
to mars... but neither is really necessary and if it seems to work ok
that could be attributed to undefined behavior as well.

David

 

[Jon Bell]

The program (below) instantiates a class and then deletes it.
I would have thought that reusing the deleted pointer would
have caused an exception, but it does not - or my coding or
thinking is incorrect?

Deleting a pointer simply tells the operating system that it is free to
allocate the memory that it points to, for something else, whenever the OS
feels it is necessary. It does not actually clear that memory, or change
the pointer itself, because that would be a waste of CPU cycles in many
situations.

Therefore there is a good chance that you will actually be able to follow
that pointer to whatever it originally pointed to, for some time
thereafter... but you can't predict how long this will work.

 

[Dave Townsend]

Using VC++ (1998) compiler with PFE32 editor in Win2K Pro SP4.
(DigitalMars CD on order. )

The program (below) instantiates a class and then deletes it.
I would have thought that reusing the deleted pointer would
have caused an exception, but it does not - or my coding or
thinking is incorrect?

#include <iostream>
using namespace std;

class A {
int a;
public:
A(): a(0) { cout << " A::A()" << endl; }
~A() { cout << "~A::A()" << endl << endl; }
void print() { cout << "a = " << a << endl; }
void set(const int& aa) { a=aa; print(); }
};

int main() {

A* b = new A; // ptr
A& c = *b; // ref

b->set(10); // test ptr
c.set(5); // test ref

delete b;

try {
A& y = *b; // no problems!
y.set(55); // causes system error (msg in Dos-box)
} catch(...) { cout << "failed" << endl; exit(-1); }

cout << "No failure" << endl; // always gets here

return 0;
}

To follow up on the other replies, if you look more carefully at the
contents of the object "b" you
will see ( at least on VC++6) that after deletion, the memory used by b is
written over and the original
value a is destroyed! I tinkered a bit with this program, if you do a few
more allocations of A's, you
will eventually find that an object is allocated at the same address as b,
very nasty, now modifying b modifies
some other unrelated object! . Just goes to show, just because you don't
crash, all may not be well.

By the way, your object is too simple to cause a crash, the original
address of b would almost always point to to valid memory so deferencing it
would not cause a crash after
you delete it - just put some virtual functions in your class and try
calling one of those after deletion and then
you'll crash for sure..!

dave

 

[Alan]

news:[email protected]... [snip]

To follow up on the other replies, if you look more carefully at the
contents of the object "b" you
will see ( at least on VC++6) that after deletion, the memory used by b is
written over and the original
value a is destroyed! I tinkered a bit with this program, if you do a few
more allocations of A's, you
will eventually find that an object is allocated at the same address as b,
very nasty, now modifying b modifies
some other unrelated object! . Just goes to show, just because you don't
crash, all may not be well.

By the way, your object is too simple to cause a crash, the original
address of b would almost always point to to valid memory so deferencing it
would not cause a crash after
you delete it - just put some virtual functions in your class and try
calling one of those after deletion and then
you'll crash for sure..!

dave

Thanks Dave, John and David.

 

[Alan]

news:[email protected]... [snip]
To follow up on the other replies, if you look more carefully at the
contents of the object "b" you
will see ( at least on VC++6) that after deletion, the memory used by b is
written over and the original
value a is destroyed! I tinkered a bit with this program, if you do a few
more allocations of A's, you
will eventually find that an object is allocated at the same address as b,
very nasty, now modifying b modifies
some other unrelated object! . Just goes to show, just because you don't
crash, all may not be well.

By the way, your object is too simple to cause a crash, the original
address of b would almost always point to to valid memory so deferencing it
would not cause a crash after
you delete it - just put some virtual functions in your class and try
calling one of those after deletion and then
you'll crash for sure..!

dave

I've put a virtual function in but it didn't fail until I introduced a static
variable into the class for instance counting. I've cut and cut the
original program.. The code below (I'm using VC++6 too) succeeds
or fails, per user choice. What puzzles me is why one class fails and
the other doesn't - as the differences appear small.

#include <iostream>
using namespace std;

class Failure {
int a;
static int count; // count instances, display them
public:
Failure(): a(0) { cout << "constructor " << count++ << endl; }
~Failure() { cout << "destructor " << --count << endl; }
virtual void set(const int& aa) { a=aa; }
};

class Success {
int a;
static int count; // count instances, no display
public:
Success(): a(0) { count++; cout << "constructor ?" << endl; }
~Success() { --count; cout << "destructor ?" << endl; }
virtual void set(const int& aa) { a=aa; }
};

int Failure::count = 1;
int Success::count = 1;

int main(int argc) {

// no command line arguments (succeeds)
if( argc == 1 )

Success* s = new Success;
delete s;
cout << "class Success *s: try { s->set(1000) }" << endl;
try {
s->set(1000);
} catch(...) { cout << "try failed" << endl; exit(-1); }
}

// one or more command line arguments (fails)
else {
Failure* f = new Failure;
delete f;
cout << "class Failure *f: try { f->set(1000) }" << endl;
try {
f->set(1000);
} catch(...) { cout << "try failed" << endl; exit(-1); }
}

cout << "No failure" << endl;
return 0;
}

Regards,
Alan

 

[Alan]

news:[email protected]... [snip]
To follow up on the other replies, if you look more carefully at the
contents of the object "b" you
will see ( at least on VC++6) that after deletion, the memory used by b is
written over and the original
value a is destroyed! I tinkered a bit with this program, if you do a few
more allocations of A's, you
will eventually find that an object is allocated at the same address as b,
very nasty, now modifying b modifies
some other unrelated object! . Just goes to show, just because you don't
crash, all may not be well.

By the way, your object is too simple to cause a crash, the original
address of b would almost always point to to valid memory so deferencing it
would not cause a crash after
you delete it - just put some virtual functions in your class and try
calling one of those after deletion and then
you'll crash for sure..!

dave

I've put a virtual function in but it didn't fail until I introduced a static
variable into the class for instance counting. I've cut and cut the
original program.. The code below (I'm using VC++6 too) succeeds
or fails, per user choice. What puzzles me is why one class fails and
the other doesn't - as the differences appear small.

#include <iostream>
using namespace std;

class Failure {
int a;
static int count; // count instances, display them
public:
Failure(): a(0) { cout << "constructor " << count++ << endl; }
~Failure() { cout << "destructor " << --count << endl; }
virtual void set(const int& aa) { a=aa; }
};

class Success {
int a;
static int count; // count instances, no display
public:
Success(): a(0) { count++; cout << "constructor ?" << endl; }
~Success() { --count; cout << "destructor ?" << endl; }
virtual void set(const int& aa) { a=aa; }
};

int Failure::count = 1;
int Success::count = 1;

int main(int argc) {

// no command line arguments (succeeds)
if( argc == 1 )

Success* s = new Success;
delete s;
cout << "class Success *s: try { s->set(1000) }" << endl;
try {
s->set(1000);
} catch(...) { cout << "try failed" << endl; exit(-1); }
}

// one or more command line arguments (fails)
else {
Failure* f = new Failure;
delete f;
cout << "class Failure *f: try { f->set(1000) }" << endl;
try {
f->set(1000);
} catch(...) { cout << "try failed" << endl; exit(-1); }
}

cout << "No failure" << endl;
return 0;
}

Regards,
Alan

There is an opening brace missing after "if( argc == 1 )",
should read "if(argc == 1) {"
I can't explain it - it is there in the original file ;-)

 

[Tom Widmer]

I've put a virtual function in but it didn't fail until I introduced a static
variable into the class for instance counting. I've cut and cut the
original program.. The code below (I'm using VC++6 too) succeeds
or fails, per user choice. What puzzles me is why one class fails and
the other doesn't - as the differences appear small.

That's the nature of undefined behaviour. Understanding why it has a
certain effect often requires intimite knowledge of the compiler and its
optimizations. The policy is to *never* write any code that has
undefined behaviour, since even if such code appears to work here and
now, as soon as you demo the system to an investor, it will almost
certainly crash.

Tom

 

[Alan]

That's the nature of undefined behaviour. Understanding why it has a
certain effect often requires intimite knowledge of the compiler and its
optimizations. The policy is to *never* write any code that has
undefined behaviour, since even if such code appears to work here and
now, as soon as you demo the system to an investor, it will almost
certainly crash.

If you could give me an example of the try..catch sequence (where the
'try' fails and the 'catch' catches it) in code that has no undefined
behaviour - it would be most helpful.

tia
sincerely,
-Alan

 

[Jonathan Mcdougall]

If you could give me an example of the try..catch sequence (where the
'try' fails and the 'catch' catches it) in code that has no undefined
behaviour - it would be most helpful.

Try-catch blocks are used with throw. If nothing throws, a try-catch is
useless.

int main()
{
try
{
throw 2;
}
catch (int i)
{
std::cout << i << " was catched.";
}
}

But I fail to see the point of your question. Using invalid pointers
don't throw exceptions, it breaks your program.


Jonathan