如果“throw”未能为异常对象分配内存会怎样？

Question

来自 C++11 标准 (15.1.p4)：

异常对象的内存以未指定的方式分配 方式，除非在 3.7.4.1 中注明

如果分配失败怎么办——它会抛出std::bad_alloc 吗？致电std::terminate?未指定？

Answer 1

（提供我自己的答案...我会等几天，如果没有问题 - 我会将其标记为已接受）

我花了一些时间对此进行调查，这是我发现的：

• C++ 标准没有指定在这种情况下会发生什么
• Clang 和 GCC 似乎使用 C++ Itanium ABI

Itanimum ABI 建议使用堆来处理异常：

抛出异常需要存储。这种存储必须 在堆栈展开时持续存在，因为它将被 处理程序，并且必须是线程安全的。异常对象存储将 因此通常在堆中分配

...

内存将由__cxa_allocate_exception 运行时库例程分配。

所以，是的...抛出异常可能涉及锁定互斥锁和搜索空闲内存块。 :-(

它还提到了这一点：

如果 __cxa_allocate_exception 在这些约束下无法分配异常对象，它会调用 terminate()

是的...在 GCC 和 Clang 中“throw myX();”可以杀死您的应用程序，而您对此无能为力（也许编写自己的 __cxa_allocate_exception 会有所帮助 - 但它肯定不会是可移植的）

它变得更好：

3.4.1 分配异常对象

异常对象的内存将由 __cxa_allocate_exception 运行时库例程，一般要求如第 2.4.2 节所述。如果正常分配 失败，然后它将尝试分配紧急缓冲区之一， 在第 3.3.1 节中描述，在以下约束条件下：

• 异常对象大小（包括标头）小于 1KB。
• 当前线程尚未拥有四个缓冲区。
• 持有缓冲区的其他线程少于 16 个，或 此线程 将等到其中一个释放其缓冲区，然后再获取一个。

是的，您的程序可以简单地挂起！这种可能性很小——您需要耗尽内存，并且您的线程需要用完所有 16 个紧急缓冲区并等待另一个应该生成异常的线程。但是如果你用std::current_exception 做事（比如链接异常并在线程之间传递它们）——这并不是那么不可能。

结论：

这是 C++ 标准的一个缺陷——你不能编写 100% 可靠的程序（使用异常）。教科书示例是一个服务器，它接受来自客户端的连接并执行提交的任务。处理问题的明显方法是抛出异常，这将解除一切并关闭连接——所有其他客户端不会受到影响，服务器将继续运行（即使在内存不足的情况下）。唉，这样的服务器是不可能用 C++ 编写的。

您可以声称现代系统（即 Linux）无论如何都会在我们达到这种情况之前杀死此类服务器。但是（1）它不是一个论点； (2)内存管理器可以设置为overcommit； (3) 运行在 64 位硬件上且内存足够的 32 位应用程序（或应用程序人为限制内存分配）不会触发 OOM 杀手。

就我个人而言，我对这个发现非常生气——多年来我一直声称我的代码可以优雅地处理内存不足。原来我对我的客户撒了谎。 :-( 不妨开始拦截内存分配，调用std::terminate 并将所有相关函数视为noexcept - 这肯定会让我的生活更轻松（编码方面）。难怪他们仍然使用Ada来编程火箭。

Answer 2

[intro.compliance]/2 尽管本国际标准仅规定了对 C++ 实现的要求，但如果将这些要求表述为对程序、程序的一部分或执行的要求，则通常更容易理解的节目。此类要求的含义如下：

(2.1) — 如果程序不违反本国际标准中的规则，则符合标准的实现应在其资源限制内接受并正确执行该程序。

强调我的。基本上，该标准设想未能分配动态内存（并在这种情况下规定行为），但没有任何其他类型的内存；并且没有以任何方式规定实现在达到其资源限制时应该做什么。

另一个例子是由于递归太深而导致堆栈耗尽。标准没有说明允许递归的深度。产生的堆栈溢出是实现在“资源限制内”执行失败的权利。

Answer 3

当前答案已经描述了 GCC 的作用。我检查了 MSVC 行为 - 它在堆栈上分配异常，因此分配不依赖于堆。这使得堆栈溢出成为可能（异常对象可能很大），但标准C++没有涵盖堆栈溢出处理。

我使用这个简短的程序来检查异常抛出期间发生的情况：

#include <iostream>

class A {
public:
    A() { std::cout << "A::A() at " << static_cast<void *>(this) << std::endl; }
    A(const A &) { std::cout << "A::A(const A &) at " << static_cast<void *>(this) << std::endl; }
    A(A &&) { std::cout << "A::A(A &&) at " << static_cast<void *>(this) << std::endl; }
    ~A() { std::cout << "A::~A() at " << static_cast<void *>(this) << std::endl; }
    A &operator=(const A &) = delete;
    A &operator=(A &&) = delete;
};

int main()
{
    try {
        try {
            try {
                A a;
                throw a;
            } catch (const A &ex) {
                throw;
            }
        } catch (const A &ex) {
            throw;
        }
    } catch (const A &ex) {
    }
}

当使用 GCC 构建时，输出清楚地表明抛出的异常被分配到远离堆栈的地方：

A::A() at 0x22cad7
A::A(A &&) at 0x600020510
A::~A() at 0x22cad7
A::~A() at 0x600020510

当使用 MSVC 构建时输出显示异常分配在堆栈附近：

A::A() at 000000000018F4E4
A::A(A &&) at 000000000018F624
A::~A() at 000000000018F4E4
A::~A() at 000000000018F624

使用调试器进行的额外检查表明，catch 处理程序和析构函数在堆栈顶部执行，因此堆栈消耗随着每个 catch 块从第一次 throw 开始而增长，直到 std::uncaught_exceptions() 变为 0。

这种行为意味着正确的内存不足处理需要您证明有足够的堆栈空间供程序执行异常处理程序和所有在途的析构函数。

要证明与 GCC 相同，您似乎需要证明嵌套异常不超过四个，并且异常的大小小于 1KiB（这包括标头）。另外，如果某个线程有四个以上的嵌套异常，还需要证明不存在紧急缓冲区分配导致的死锁。

Answer 4

实际上规定如果异常对象分配失败，则应抛出bad_alloc，实现也可以调用新的处理程序。

这实际上是在您的站点 [basic.stc.dynamic.allocation] 的 c++ 标准部分（第 3.7.4.1 节）中指定的：

分配存储失败的分配函数可以调用当前安装的新处理函数 (21.6.3.3)，如果有的话。 [ 笔记： 程序提供的分配函数可以获得当前的地址 已安装 新处理程序 使用 std::get_new_handler 功能（21.6.3.4）。 ——尾注 ] 如果一个分配 具有非抛出异常规范 (18.4) 的函数无法分配存储，它应返回 null 指针。任何其他分配存储失败的分配函数只能通过抛出一个 与类型的处理程序 (18.3) 匹配的类型的异常 (18.1) std::bad_alloc (21.6.3.1)。

然后在[except.terminate]中召回

在某些情况下，必须放弃异常处理以使用不太微妙的错误处理技术。 [ 笔记： 这些情况是： — (1.1) 异常处理机制时，在完成异常对象的初始化后但是 在激活异常处理程序之前 (18.1)*

所以安腾 ABI 不遵循 c++ 标准规范，因为如果程序无法为异常对象分配内存，它可以阻塞或调用terminate。