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

Question

事实证明，许多看似无辜的事情在 C++ 中都是未定义的行为。例如，一旦非空指针被删除，即使打印出该指针值也是未定义的行为。

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

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

我对这句话的解读：

[...] 对于具有非平凡析构函数的类类型的对象，程序不需要在重用或释放该对象占用的存储空间之前显式调用析构函数；但是，如果没有显式调用析构函数，或者如果 删除表达式
(expr.delete) 不用于释放存储，析构函数不得被隐式调用，并且任何依赖于析构函数产生的副作用的程序都具有未定义的行为。

- C++20 标准，[basic.life] p5

如下：

如果您设法释放对象占用的存储而不调用占用内存的对象的析构函数，则结果是 UB，如果析构函数并不简单并且有副作用。

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

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

---

注意：所引用段落中的 UB 已被 CWG Issue 2523 因为它在常量表达式中是不可诊断的。工作草案中的[basic.life] p5不再包含此内容。

Answer 5

（下面评论“注意：此答案已从 https 移至此处://stackoverflow.com/questions/24137006/does-a-memory-leak-cause-undefined-behaviour" - 您可能必须阅读该问题才能获得此答案的正确背景O_o）。

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

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

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

我不明白为什么标准选择不定义行为（直到 C++23）当存在副作用依赖性时 - 而不是简单地说这些副作用不会发生并让程序定义或< /em> 在这个前提下，未定义的行为正如您通常所期望的那样。

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

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

注意：此措辞已在 C++23 中删除，请参阅 [basic. life] p5

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

访问由易失性泛左值（3.10）指定的对象、修改对象、调用库 I/O 函数或调用执行任何这些操作的函数都是端效果，即执行环境状态的变化。

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

可以说与第 3.8 p4 节中的场景相匹配的依赖关系示例（其中未定义行为的需求或原因并不明显）是：

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

int main()
{
     new X();
}

人们争论的一个问题是是否会考虑上面的 X 对象出于 3.8 p4 的目的而发布，因为它可能仅在程序终止后发布到操作系统 - 通过阅读标准并不清楚进程“生命周期”的该阶段是否在标准行为的范围内要求（我对标准的快速搜索并没有澄清这一点）。我个人认为 3.8p4 在这里适用，部分原因是只要它足够模糊，编译器编写者可能会觉得有权在这种情况下允许未定义的行为，但即使上面的代码不构成发布，这种情况也很容易修改了 ala...

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 () 因此将删除 p_ 已释放的指针，从而创建未定义的行为。如果x.~X();在重用之前被调用，p_将被设置为0并且删除将是安全的。从这个意义上说，程序的正确行为可以说取决于析构函数，并且该行为显然是未定义的，但是我们是否刚刚编写了一个与 3.8p4 所描述的行为本身相匹配的程序，而不是让该行为成为结果3.8p4...？

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

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

Answer 6

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

自然没有拿出任何证据。

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

---

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

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

这段文字在 C++98 和 C++03 中具有完全相同的措辞（但是，UB 在 C++23 中被删除，请参阅 [basic.life] p5 作者：CWG 2523）。这是什么意思？

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

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

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

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

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

---

看过注释的人可能会注意到，上面对“应”一词的解释并不是我之前假设的含义。正如我现在所看到的，“应该”并不是实施的要求，也不是允许做什么的要求。这是对程序的要求，即允许代码执行的操作。

因此，这在形式上是 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 放置：

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 7

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

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

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

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

Answer 8

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

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

这里会不会导致UB，会提到，所以它是“只是内存泄漏”。

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

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

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

Answer 9

它绝对是定义的行为。

考虑服务器正在运行并不断分配堆内存的情况，即使不使用内存也不会释放内存。
因此，最终结果将是服务器最终将耗尽内存并且肯定会发生崩溃。

Answer 10

如果航天飞机必须在两分钟内起飞，并且我可以在将其放入泄漏内存的代码和具有未定义行为的代码之间进行选择，那么我将放入泄漏内存的代码。

但我们大多数人通常不会遇到这种情况，即使遇到这种情况，也可能是因为进一步的失败。也许我错了，但我把这个问题理解为“哪种罪会让我更快地进入地狱？”

可能是未定义的行为，但实际上两者都是。

Answer 11

定义，因为内存泄漏是指您忘记自行清理。

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

Answer 12

直接回答：标准没有定义泄漏内存时会发生什么，因此它是“未定义的”。但它是隐式未定义的，这比标准中显式未定义的东西没那么有趣。

Answer 13

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

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

Answer 14

未定义的行为意味着将发生什么尚未定义或未知。在 C/C++ 中，众所周知，内存泄漏的行为会消耗可用内存。然而，由此产生的问题并不总是能够按照游戏结束的描述进行定义和变化。