C ++中的内存泄漏“未定义行为”类问题吗？

Question

事实证明，许多看起来很天真的东西在 C++ 中是未定义的行为。例如，一旦一个非空指针被delete'd even printing out that pointer value is undefined behavior。

现在内存泄漏肯定很糟糕。但是它们是什么类别的情况 - 已定义、未定义或其他什么类别的行为？

Answer 1

内存泄漏。

没有未定义的行为。泄漏内存是完全合法的。

未定义的行为：是标准明确不想定义并留给实现的操作，以便在不违反标准的情况下灵活地执行某些类型的优化。

内存管理定义明确。
如果您动态分配内存并且不释放它。然后，内存仍然是应用程序的属性，可以按照它认为合适的方式进行管理。您丢失了对那部分内存的所有引用这一事实既不存在也不存在。

当然，如果您继续泄漏，那么您最终将耗尽可用内存并且应用程序将开始抛出 bad_alloc 异常。但这是另一个问题。

Answer 2

内存泄漏肯定是在 C/C++ 中定义的。

如果我这样做：

int *a = new int[10];

紧随其后

a = new int[10]; 

我肯定会泄漏内存，因为无法访问第一个分配的数组，并且由于不支持 GC，因此不会自动释放该内存。

但是这种泄漏的后果是不可预测的，并且会因应用程序而异，对于相同的给定应用程序也会因机器而异。假设由于在一台机器上泄漏而崩溃的应用程序可能在另一台具有更多 RAM 的机器上运行良好。此外，对于给定机器上的给定应用程序，由于泄漏导致的崩溃可能会在运行期间的不同时间出现。

Answer 3

如果您泄漏内存，则执行将继续进行，就好像什么都没发生一样。这是定义的行为。

接下来，您可能会发现调用malloc 失败是因为没有足够的可用内存。但这是malloc的定义行为，后果也很明确：malloc调用返回NULL。

现在这可能会导致不检查malloc 结果的程序因分段违规而失败。但是这种未定义的行为（来自语言规范的 POV）是由于程序取消引用无效指针，而不是早期的内存泄漏或失败的 malloc 调用。

Answer 4

我对这句话的解读：

对于具有非平凡析构函数的类类型的对象， 程序不需要在调用之前显式调用析构函数 对象占用的存储空间被重用或释放；然而，如果 没有显式调用析构函数或删除表达式 (5.3.5) 不用于释放存储，析构函数不得 被隐式调用以及依赖于副作用的任何程序 析构函数产生的行为未定义。

如下：

如果你设法释放了对象占用的存储空间 没有在占用内存的对象上调用析构函数，如果析构函数是重要且有副作用。

如果new 用malloc 分配，原始存储可以用free() 释放，析构函数不会运行，会导致UB。或者如果一个指针被强制转换为不相关的类型并被删除，内存被释放，但错误的析构函数运行，UB。

这与省略的delete 不同，后者不会释放底层内存。省略 delete 不是 UB。

Answer 5

（在“提示：此答案已从 Does a memory leak cause undefined behaviour? 移至此处”下方评论 - 您可能必须阅读该问题才能获得此答案的正确背景 O_o）。

在我看来，这部分标准明确允许：

• 拥有一个自定义内存池，您可以将-new 对象放入其中，然后释放/重用整个内容，而无需花时间调用它们的析构函数，只要您不依赖对象析构函数的副作用。

• 分配一点内存但从不释放它的库，可能是因为它们的函数/对象可以被静态对象的析构函数和注册的退出处理程序使用，而且不值得购买整个编排顺序每次这些访问发生时，都会发生毁灭性的或短暂的“凤凰”般的重生。

我无法理解为什么当存在对副作用的依赖时，标准选择不定义行为 - 而不是简单地说这些副作用不会有发生了，让程序定义或未定义的行为，就像你通常期望的那样。

我们可以仍然考虑什么标准所说的未定义行为。关键部分是：

“取决于析构函数产生的副作用有未定义的行为。”

标准 §1.9/12 明确定义副作用如下（以下斜体为标准，表示引入了正式定义）：

访问由volatile glvalue (3.10) 指定的对象、修改对象、调用库 I/O 函数或调用执行任何这些操作的函数都是副作用 ，即执行环境状态的变化。

在您的程序中，没有依赖关系，因此没有未定义的行为。

一个可以说与§3.8 p4 中的场景相匹配的依赖示例是：

struct X
{
    ~X() { std::cout << "bye!\n"; }
};

int main()
{
     new X();
}

人们正在争论的一个问题是上面的 X 对象是否会被视为 3.8 p4 的目的 released，因为它可能只发布到操作系统。程序终止后 - 从阅读标准中不清楚流程“生命周期”的那个阶段是否在标准的行为要求范围内（我对标准的快速搜索没有澄清这一点）。我个人认为 3.8p4 在这里适用，部分原因是只要它足够模棱两可，编译器编写者可能会觉得有权在这种情况下允许未定义的行为，但即使上面的代码不构成释放场景的容易修改啦...

int main()
{
     X* p = new X();
     *(char*)p = 'x';   // token memory reuse...
}

无论如何，尽管 main 实现了上面的析构函数有一个副作用 - 每个“调用库 I/O 函数”；此外，程序的可观察行为可以说是“依赖于”它，因为如果它已经运行，会受到析构函数影响的缓冲区在终止期间被刷新。但是“取决于副作用”仅是否意味着暗示如果析构函数没有运行，程序显然会有未定义的行为的情况？我会在前者方面犯错，特别是因为后一种情况不需要标准中的专用段落来记录行为未定义。这是一个明显未定义行为的示例：

int* p_;

struct X
{
    ~X() { if (b_) p_ = 0; else delete p_; }
    bool b_;
};

X x{true};

int main()
{
     p_ = new int();
     delete p_; // p_ now holds freed pointer
     new (&x){false};  // reuse x without calling destructor
}

在终止期间调用x 的析构函数时，b_ 将是false，因此~X() 将delete p_ 用于已释放的指针，从而创建未定义的行为。如果在重用之前调用了x.~X();，则p_ 将被设置为0，并且删除将是安全的。从这个意义上说，程序的正确行为可以说取决于析构函数，并且行为显然是未定义的，但是我们是否只是制作了一个与 3.8p4 描述的行为本身匹配的程序，而不是让行为成为结果3.8p4...？

有问题的更复杂的场景 - 太长而无法提供代码 - 可能包括例如一个奇怪的 C++ 库，在文件流对象中具有引用计数器，必须达到 0 才能触发某些处理，例如刷新 I/O 或加入后台线程等 - 不做这些事情的风险不仅在于无法执行明确请求的输出析构函数，但也无法从流中输出其他缓冲输出，或者在某些具有事务文件系统的操作系统上可能会导致早期 I/O 的回滚 - 此类问题可能会改变可观察到的程序行为甚至使程序挂起。

注意：没有必要证明任何实际代码在任何现有编译器/系统上行为异常；标准清楚地保留了编译器具有未定义行为的权利......这就是最重要的。这不是您可以推理并选择忽略标准的事情 - 可能是 C++14 或其他一些修订版更改了此规定，但只要它存在，那么即使可以说对 有一些“依赖”副作用那么就有可能出现未定义的行为（当然，它本身允许由特定的编译器/实现来定义，所以这并不意味着每个编译器都必须做一些奇怪的事情）。

Answer 6

语言规范没有提到“内存泄漏”。从语言的角度来看，当您在动态内存中创建对象时，您正在这样做：您正在创建一个具有无限生命周期/存储持续时间的匿名对象。在这种情况下，“无限”意味着该对象只能在您显式解除分配时结束其生命周期/存储持续时间，否则它会继续永远存在（只要程序运行）。

现在，我们通常认为动态分配的对象在程序执行时成为“内存泄漏”，此时对该对象的所有引用（通用“引用”，如指针）都丢失到无法恢复的地步。请注意，即使对人类来说，“所有引用都丢失”的概念也没有得到非常精确的定义。如果我们对对象的某些部分有引用，理论上可以“重新计算”为对整个对象的引用怎么办？是不是内存泄漏？如果我们没有对该对象的任何引用，但我们可以使用程序可用的一些其他信息（如精确的分配顺序）以某种方式计算这样的引用怎么办？

语言规范本身并不关心此类问题。无论您认为程序中是否出现“内存泄漏”，从语言的角度来看，这根本不是事件。从语言的角度来看，一个“泄露的”动态分配的对象只会继续快乐地生活，直到程序结束。这是唯一剩下的问题：当程序结束并且仍然分配一些动态内存时会发生什么？

如果我没记错的话，该语言并没有指定在程序终止时仍然分配的动态内存会发生什么。不会尝试自动销毁/释放您在动态内存中创建的对象。但在这种情况下，没有正式的未定义行为。

Answer 7

举证责任在于那些认为内存泄漏可能是 C++ UB 的人。

自然没有证据。

简而言之，对于任何怀有任何怀疑的人来说，这个问题永远无法得到明确的解决，除非非常可信地威胁委员会，例如大声的贾斯汀比伯音乐，所以他们添加了一个 C++14 声明，说明它不是 UB。

---

有争议的是 C++11 §3.8/4：

” 对于具有非平凡析构函数的类类型的对象，在对象占用的存储被重用或释放之前，程序不需要显式调用析构函数；但是，如果没有显式调用析构函数，或者没有使用 delete-expression (5.3.5) 来释放存储，则不应隐式调用析构函数，并且任何依赖于析构函数产生的副作用具有未定义的行为。

这段话在 C++98 和 C++03 中的措辞完全相同。什么意思？

• 在重用或释放对象占用的存储空间之前，程序不需要显式调用析构函数
  
  – 意味着可以获取变量的内存并重用该内存，而无需首先破坏现有对象。

• 如果没有显式调用析构函数，或者如果没有使用删除表达式 (5.3.5) 来释放存储，则不应隐式调用析构函数
  
  – 意味着如果在内存重用之前没有销毁现有对象，那么如果该对象自动调用其析构函数（例如，局部自动变量），则程序具有未定义行为，因为该析构函数将在否更长的现有对象。

• 任何依赖于析构函数产生的副作用的程序都有未定义的行为
  
  – 不能从字面上理解它所说的，因为程序总是依赖于任何副作用，根据副作用的定义。或者换句话说，程序没有办法不依赖副作用，因为那样它们就不会是副作用。

很可能预期的结果不是最终进入 C++98 的内容，因此我们手头有一个缺陷。

从上下文可以猜测，如果程序依赖于自动销毁静态已知类型T 的对象，其中内存已被重用于创建一个或多个不是T 对象的对象，那么这就是未定义的行为。

---

看过评论的人可能会注意到，上面对“shall”这个词的解释并不是我之前假设的意思。正如我现在所看到的，“shall”不是实现的要求，它被允许做什么。这是对程序的要求，允许代码做什么。

因此，这是正式的 UB：

auto main() -> int
{
    string s( 666, '#' );
    new( &s ) string( 42, '-' );    //  <- Storage reuse.
    cout << s << endl;
    //  <- Formal UB, because original destructor implicitly invoked.
}

但这可以用字面解释：

auto main() -> int
{
    string s( 666, '#' );
    s.~string();
    new( &s ) string( 42, '-' );    //  <- Storage reuse.
    cout << s << endl;
    //  OK, because of the explicit destruction of the original object.
}

一个主要问题是，如果按照上面标准段落的字面解释，如果放置 new 在那里创建了一个不同类型的对象，只是因为显式破坏了原始对象，它仍然是正式的。但在这种情况下，这不是很实用。也许这被标准中的其他段落所涵盖，因此它也是正式的 UB。

这也可以，使用来自<new>的展示位置new：

auto main() -> int
{
    char* storage   = new char[sizeof( string )];
    new( storage ) string( 666, '#' );
    string const& s = *(
        new( storage ) string( 42, '-' )    //  <- Storage reuse.
        );
    cout << s << endl;
    //  OK, because no implicit call of original object's destructor.
}

正如我所见——现在。

Answer 8

它明确定义行为。

假设服务器正在运行并继续分配堆内存并且即使没有使用它也没有释放内存。 因此最终结果将是最终服务器将耗尽内存并且肯定会发生崩溃。

Answer 9

除了所有其他答案之外，还有一些完全不同的方法。查看第 5.3.4-18 节中的内存分配，我们可以看到：

如果上述对象初始化的任何部分⁷⁶终止 通过抛出异常和合适的释放函数可以 找到后，调用释放函数来释放其中的内存 正在构造对象，之后异常继续 在新表达式的上下文中传播。如果没有明确 可以找到匹配的释放函数，传播异常 不会导致对象的内存被释放。 [注：这是 当被调用的分配函数不分配时适用 记忆;否则，很可能导致内存泄漏。 ——尾注 ]

这里会不会引起UB，会提到，所以“只是内存泄漏”。

在 §20.6.4-10 等地方，提到了可能的垃圾收集器和泄漏检测器。已经对安全派生指针等概念进行了很多思考。能够将 C++ 与垃圾收集器一起使用（C.2.10“对垃圾收集区域的最小支持”）。

因此，如果 UB 只是丢失了指向某个对象的最后一个指针，那么所有的努力都将毫无意义。

关于“当析构函数有副作用时，它永远不会运行 UB”，我会说这是错误的，否则 std::quick_exit() 等设施本质上也是 UB。

Answer 10

如果航天飞机必须在两分钟内起飞，而我可以在使用泄漏内存的代码和具有未定义行为的代码之间进行选择，我将使用泄漏内存的代码。

但我们中的大多数人通常不会处于这种情况，如果是这样，那可能是由于更进一步的失败。也许我错了，但我将这个问题解读为“哪种罪会使我更快地进入地狱？”

可能是未定义的行为，但实际上两者兼而有之。

Answer 11

定义，因为内存泄漏是你忘记自己清理。

当然，内存泄漏可能会导致以后出现未定义的行为。

Answer 12

直截了当的回答：标准没有定义泄漏内存时会发生什么，因此它是“未定义的”。虽然它是隐式未定义的，但它不如标准中显式未定义的东西有趣。

Answer 13

这显然不能是未定义的行为。仅仅因为UB必须在某个时间点发生，并且忘记释放内存或调用析构函数不会在任何时间点发生。所发生的只是程序在没有释放内存或调用析构函数的情况下终止；这不会以任何方式使程序或其终止的行为未定义。

话虽如此，在我看来，标准在这段话中是自相矛盾的。一方面它确保在这种情况下不会调用析构函数，另一方面它表示如果程序依赖于析构函数产生的副作用，那么它具有未定义的行为。假设析构函数调用exit，那么没有任何程序可以假装独立于它，因为调用析构函数的副作用会阻止它执行原本会执行的操作；但文本也保证析构函数不会被调用，这样程序就可以不受干扰地继续做它的事情。我认为阅读本文结尾的唯一合理方法是，如果程序的正确行为要求调用析构函数，那么实际上没有定义行为；鉴于刚刚规定不会调用析构函数，因此这是多余的评论。

Answer 14

未定义的行为意味着，将发生的事情尚未定义或未知。内存泄漏的行为在 C/C++ 中肯定会吞噬可用内存。然而，由此产生的问题并不总是如游戏结束所描述的那样定义和变化。