在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 ++运行时应该为我自动释放这些异常（这并不像我有任何能力手动释放它们，对吗？），那么有什么原因可能导致它不能？

我确实在相同的主题上找到了这 两个问题，但是它们似乎不适用于这里，因为它们仅在特殊情况下处理单个泄漏的异常，而此代码每个请求泄漏一个异常（请注意，有11个单独的块泄漏；这是因为我在此测试中运行了11次此测试功能）。

编辑 ：我不知道它是否相关，但是值得一提的是， servehtstart和servereq是纯C程序中的函数。 _htstart及更高版本是dlopen() ed共享对象中的C ++代码。 可能只有libstdc++才是该共享库的dlopen才有意义。

Answer 1

事实证明，这是某些glibc版本中的错误，包括当前在Debian Stable（即2.13）中使用的版本，但此问题已得到修复。 在Debian Testing安装程序（使用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 commit是e6c61494 。

谢谢@ quantdev，@ DavidSchwartz。 您的评论使我意识到要寻找什么。