在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。 您的評論使我意識到要尋找什么。