Why isn't accessing a deleted object crashing my program?

Question

I have a piece of code that is creating a tile based level.

class Level {

//Variables
//===================================================
public:
    Tile *** TileGrid;  //A 2d array of pointers to tiles
    int TilesWide, TilesTall;

//Methods
//===================================================
public:
    Level::Level(char * fileName);
    Level::~Level();
    void Draw();
};

I allocate memory for the TileGrid and all is good. I have a destructor set up for the class too.

Level::~Level() {

    for (int i = 0; i < TilesTall; i++) {
        for (int j = 0; j < TilesWide; j++)
            //delete the looped tile being pointed to
            delete TileGrid[i][j];

        //delete the row
        delete [] TileGrid[i];
    }

    //delete the array of rows
    delete [] TileGrid;
}

For giggles I decided I would delete my instance of Level. After I did so, I found that I could still call its Draw method.

In the debugger the values for TilesWide and TilesTall are a huge negative numbers, so nothing draws in my for loops iterating the grid.

Would trying to access a deleted variable not cause some sort of crash?

@LuchianGrigore: No, this question is distinct. That question is about returning the address of a local variable; this is about use-after-free on the heap. — Billy ONeal, Feb 13 '13 at 20:20

score 2 · Answer 1 · answered Feb 13 '13 at 20:18

2

It won't necessarily cause a crash. It may do, it may not. It causes what is called undefined behaviour:

undefined behaviour
behavior for which this International Standard imposes no requirements

It could just as much crash as destroy the universe.

answered Feb 13 '13 at 20:18

Joseph Mansfield

108,238
20
242
324

score 2 · Answer 2 · answered Feb 13 '13 at 20:19

2

It could cause a crash. It depends if that memory is overwritten with another object and/or the memory system reallocates that page to another process (or deallocates the page from your current process). The bottom line is that you can't rely on it working (as you know already)

answered Feb 13 '13 at 20:19

Brian Agnew

268,207
37
334
440

This answer assumes the existence of "processes" and "pages", of which the standard does not know. (And on real systems, it is unlikely that an object would have an entire page for itself) – Billy ONeal Feb 13 '13 at 20:19
1

Yes. I'm not considering the standard, but actually what could happen from the OS and CPU point of view. I'm not suggesting the object has a page all to itself, but the page (depending on the OS) may be returned if it's not used by the process – Brian Agnew Feb 13 '13 at 20:20

score 1 · Answer 3 · answered Feb 13 '13 at 20:19

1

Accessing an object after deletion is undefined behavior. Undefined behavior can mean anything, from "appearing to succeed" to "crashing" to "formatting your hard disk".

answered Feb 13 '13 at 20:19

Billy ONeal

104,103
58
317
552

score 1 · Accepted Answer · answered Feb 13 '13 at 20:22

What you have done is known as "Undefined behavior".

And undefined behavior doesn't mean "will crash", it means anything can happen. The program could format your hard drive, it could play a Bach sonata, it could draw a picture of daffy duck on the screen, it could give you a negative value, and in every case it would be exactly what you asked for.

Not crashing is included, as is crashing.

Now let us suppose a reasonably sane implementation of C++. The method Level::Draw does not vary with which instance of Level you pass it, so what function you call doesn't rely on the instance. The instance is passed as a parameter to this function as a pointer that points to some memory in the heap that used to be a copy of the variable. Since then, it has been recycled for some other purpose, or maybe contains book-keeping information about the heap -- what is there is undefined. (And, accessing it could segfault if the runtime returned the page to the system)

You then proceed to interpret that garbage as some values. Things are perfectly fine, because random garbage looks like a C++ integer (in this case, as a negative integer) pretty much always on most systems.

Now, once you start dereferencing pointers (and as such, accessing "random" parts of memory), or writing to the state of this, crashing is likely to happen (if not then, then later, or elsewhere).

Why isn't accessing a deleted object crashing my program?

4 Answers4

Linked

Related