c++ - 抛出的异常在 C++ 中被泄露

Question

我在 C++ 上玩了一会儿，其中有一段“可重新启动”的代码。即:

class handler {
public:
    virtual ~handler() {}
    virtual response handle(request &req) = 0;
};

response dispatch(request &req, handler &hnd) {
    try {
        return(hnd.handle(req));
    } catch(handler &rep) {
        return(dispatch(req, rep));
    }
}

然后，在另一部分代码中:

static response serve(request &req) {
    throw(resp::message("Merdel", {"Test"}));
}

其中 resp::message 是 handler 的子类。

这似乎工作正常，但是当我在 Valgrind 上运行它时，它告诉我这会泄漏内存:

==2609== 352 bytes in 11 blocks are definitely lost in loss record 12 of 16
==2609==    at 0x4C270FE: memalign (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==2609==    by 0x4010BEF: tls_get_addr_tail (dl-tls.c:529)
==2609==    by 0x401110F: __tls_get_addr (dl-tls.c:767)
==2609==    by 0x668FC9B: __cxa_get_globals (eh_globals.cc:63)
==2609==    by 0x668F5EE: __cxa_allocate_exception (eh_alloc.cc:132)
==2609==    by 0x61DDA5E: serve(arw::request&) (arwtest.ashc:7)
==2609==    by 0x640E18B: arw::funhandler::handle(arw::request&) (arw.cpp:95)
==2609==    by 0x640E1C5: arw::dispatch(arw::request&, arw::handler&) (arw.cpp:100)
==2609==    by 0x640E487: arw::dispatch(ashd::request const&, arw::handler&) (arw.cpp:119)
==2609==    by 0x61DDBA7: _htstart (arwtest.ashc:11)
==2609==    by 0x403CCD: servehtstart (request.c:228)
==2609==    by 0x4040C5: servereq (request.c:303)

serve(arw::request&) (arwtest.ashc:7) 是上面列出的 serve 函数。

为什么会泄漏内存？据我了解，C++ 运行时应该自动为我释放这些异常(而且我也没有任何能力手动释放它们，对吧？)，那么什么会导致它不释放？

我确实找到了 these two以前关于类似主题的问题，但它们似乎不适用于此处，因为它们仅在特殊情况下处理单个泄漏异常，而此代码会在每个请求中泄漏一个异常(请注意泄漏了 11 个单独的 block ；这是因为在此测试期间，我运行了此测试函数 11 次)。

编辑:我不知道它是否相关，但可能值得注意的是回溯中的 servehtstart 和 servereq是纯 C 程序中的函数。 _htstart 及以上是来自 dlopen()ed 的共享对象的 C++ 代码。也可能只有此共享对象的 dlopen 才将 libstdc++ 带入进程。

Answer 1

事实证明，这是某些 glibc 版本中的错误，包括当前在 Debian Stable 中的版本(即 2.13)，但此后已修复。在 Debian 测试设置(使用 glibc 2.19)上运行相同的程序时，不会发生内存泄漏。

显然，glibc 2.13 没有正确清理由dlopen()'ed 对象引入的线程本地内存。它出现在这里是因为 libstdc++ 仅作为 dlopen() 的结果加载。之前在这两个错误报告中描述了该问题:

• https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39366
• https://sourceware.org/bugzilla/show_bug.cgi?id=12650

修复问题的 glibc 提交是 e6c61494 .

感谢@quantdev、@DavidSchwartz。您的评论让我意识到要寻找什么。