当你在 C++ 中释放一个指针两次或更多次时会发生什么？

Question

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

    delete e;
    delete e;
    ...
    delete e;
    return 0;
}

Answer 1

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.

Answer 2

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.

Answer 3

除了关于“未定义行为”的旧观点，这意味着任何事情都可能发生，从无到有到通往在主内存中打开的地狱第七圈的网关，实际上，在大多数实现中通常会发生的是程序将继续运行删除，然后在某个不相关的内存分配中神秘地崩溃。

Answer 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]

Answer 5

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.

Answer 6

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.

Answer 7

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