What happens when you deallocate a pointer twice or more in C++?
Asked Answered
A

8

30
int main() {
    Employee *e = new Employee();

    delete e;
    delete e;
    ...
    delete e;
    return 0;
}
Arthralgia answered 30/4, 2010 at 18:12 Comment(2)
out of cucumber error restart universe.Brunelleschi
Why the downvote? Its a simple & straightforward question. Just because you think it's an elementary question doesn't mean it should be d/v'ed.Externalism
I
47

You get undefined behaviour if you try to delete an object through a pointer more than once.

This means that pretty much anything can happen from 'appearing to work' to 'crashing' or something completely random.

Intwine answered 30/4, 2010 at 18:13 Comment(2)
I've tried it and it doesn't crash. But what I think is that you might deallocate memory that other part of your program is using.Arthralgia
It might not crash at that moment. But if it corrupts part of the heap, then there's a significant chance that a crash could happen at some arbitrary point afterwards. However, it could become something of a lurking time-bomb. Not causing any problem until later when some seemingly unrelated action happens to touch the corrupted part and then boomRile
M
21

It's undefined behavior, so anything can happen.

What's likely to happen is bad. Typically, the free store is a carefully managed system of free and allocated blocks, and new and delete do bookkeeping to keep everything in a consistent state. If you delete again, the system is likely to do the same bookkeeping on invalid data, and suddenly the free store is in an inconsistent state. This is known as "heap corruption".

Once that happens, anything you do with new or delete may have unpredictable results, which can include attempting to write outside the application's memory area, silently corrupting data, erroneously thinking there's no more memory, or double or overlapping allocation. If you're lucky, the program will crash soon, although you'll still have problems figuring out why. If you're unlucky, it will continue to run with bad results.

Madalena answered 30/4, 2010 at 18:19 Comment(0)
O
13

Aside from the old saw about "undefined behavior" meaning anything could happen from nothing to a gateway to the seventh circle of the inferno opening up in main memory, in practice what will usually happen in most implementations is that the program will continue to run past the deletes, and then mysteriously crash sometime later in some unrelated memory allocation.

Owings answered 30/4, 2010 at 18:17 Comment(2)
Yes, and that's one of the better things that can happen.Madalena
often When I get the mysterious memory crashes, I WISH a gateway to the seventh circle of the inferno had opened up in main memory instead...Brunelleschi
P
4

You are likely venturing into 'undefined behavior' territory.

On many systems this will cause a crash; for example, on my Linux machine:

*** glibc detected *** ./cctest: double free or corruption (fasttop): 0x0000000000d59900 ***
======= Backtrace: =========
/lib/libc.so.6[0x7f399f4cbdd6]
/lib/libc.so.6(cfree+0x6c)[0x7f399f4d074c]
./cctest[0x400a7a]
/lib/libc.so.6(__libc_start_main+0xfd)[0x7f399f474abd]
./cctest[0x400959]
Porshaport answered 30/4, 2010 at 18:15 Comment(0)
K
3

If you're really lucky it will crash. What normally happens is it stores up karma until your CEO is demonstrating the code to your most important new customer when it will corrupt/destroy all of their data.

In checked or debug builds often this kind of thing is caught, but it can go completely undetected and cause havoc later. This is especially profound when multiple threads get involved.

Kreda answered 30/4, 2010 at 18:48 Comment(0)
W
3

If you are worried this might happen in your apps, either stop using raw pointers completely, so that you don't need delete (eg switch over to shared_ptr) or always set pointers to NULL (or 0, or better still nullptr) after you delete them. Calling delete on a null pointer is guaranteed to do nothing.

Woolgrower answered 30/4, 2010 at 20:38 Comment(1)
I've always disliked the latter solution. Deleting a pointer twice is bad, and setting pointers to null is just going to hide the problem.Kettledrum
S
2

It's not safe, and it's undefined what might actually happen:

http://www.parashift.com/c++-faq-lite/freestore-mgmt.html#faq-16.2

Shellieshellproof answered 30/4, 2010 at 18:13 Comment(0)
H
0

Even though sometimes we can access the memory location after deleting ptr. we shouldn't delete same pointer again or assign value to that pointer( leads to inconsistent behavior).

But we can use same pointer variable to point different memory address ( valid memory)

int *p = new int(10);
std::cout << "in main" << std::endl;
std::cout <<*p << std::endl;
std::cout << p << std::endl;
std::cout << &p<< std::endl;
delete p;
std::cout << "in main2 after delete" << std::endl;
std::cout <<*p << std::endl;
std::cout << p << std::endl;
std::cout << &p<< std::endl;

p = new int(100);
std::cout << "in main3" << std::endl;
std::cout <<*p << std::endl;
std::cout << p << std::endl;
std::cout << &p<< std::endl;

leads to output

in main
10
0x558b597a8eb0
0x7fff8f7a5ba0
in main2 after delete
0
0x558b597a8eb0
0x7fff8f7a5ba0
in main3
100
0x558b597a8eb0
0x7fff8f7a5ba0
Hobo answered 30/9, 2021 at 9:9 Comment(0)

© 2022 - 2025 — McMap. All rights reserved.