valgrind檢測到的內存泄漏和庫中的錯誤

Question

對C ++來說是非常新的東西，但是卻可以接觸到我白天玩的valgrind。 我的代碼很好地清理了，除了使用外部庫（xqilla）的部分。 我看到的是內存泄漏和錯誤。 這是否意味着我應該看一個不同的庫，還是庫中有我不關心的錯誤和小泄漏是常見的？

---

Valgrind輸出

==8779== Syscall param sendmsg(mmsg[0].msg_hdr) points to uninitialised byte(s)
==8779==    at 0x6065829: sendmmsg (sendmmsg.c:32)
==8779==    by 0x767C8FD: __libc_res_nsend (res_send.c:1140)
==8779==    by 0x7679D48: __libc_res_nquery (res_query.c:226)
==8779==    by 0x767A6F8: __libc_res_nsearch (res_query.c:582)
==8779==    by 0x746CB57: _nss_dns_gethostbyname4_r (dns-host.c:314)
==8779==    by 0x6035ADF: gaih_inet (getaddrinfo.c:849)
==8779==    by 0x6039913: getaddrinfo (getaddrinfo.c:2473)
==8779==    by 0x50B3F06: xercesc_3_1::UnixHTTPURLInputStream::UnixHTTPURLInputStream(xercesc_3_1::XMLURL const&, xercesc_3_1::XMLNetHTTPInfo const*) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779==    by 0x50B3A44: xercesc_3_1::SocketNetAccessor::makeNew(xercesc_3_1::XMLURL const&, xercesc_3_1::XMLNetHTTPInfo const*) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779==    by 0x4F8813A: xercesc_3_1::XMLURL::makeNewStream() const (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779==    by 0x4FEC737: xercesc_3_1::ReaderMgr::createReader(xercesc_3_1::InputSource const&, bool, xercesc_3_1::XMLReader::RefFrom, xercesc_3_1::XMLReader::Types, xercesc_3_1::XMLReader::Sources, bool, unsigned long) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779==    by 0x4FE6758: xercesc_3_1::IGXMLScanner::scanReset(xercesc_3_1::InputSource const&) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779==  Address 0x7feffdad0 is on thread 1's stack
==8779== 
Hello
Good
Bye
==8779== 
==8779== HEAP SUMMARY:
==8779==     in use at exit: 11 bytes in 1 blocks
==8779==   total heap usage: 8,144 allocs, 8,143 frees, 1,957,496 bytes allocated
==8779== 
==8779== 11 bytes in 1 blocks are definitely lost in loss record 1 of 1
==8779==    at 0x4C2A879: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8779==    by 0x4FEC508: xercesc_3_1::MemoryManagerImpl::allocate(unsigned long) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779==    by 0x50B87D5: xercesc_3_1::IconvGNULCPTranscoder::transcode(unsigned short const*, xercesc_3_1::MemoryManager*) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779==    by 0x50B3C6D: xercesc_3_1::UnixHTTPURLInputStream::UnixHTTPURLInputStream(xercesc_3_1::XMLURL const&, xercesc_3_1::XMLNetHTTPInfo const*) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779==    by 0x50B3A44: xercesc_3_1::SocketNetAccessor::makeNew(xercesc_3_1::XMLURL const&, xercesc_3_1::XMLNetHTTPInfo const*) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779==    by 0x4F8813A: xercesc_3_1::XMLURL::makeNewStream() const (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779==    by 0x4FEC737: xercesc_3_1::ReaderMgr::createReader(xercesc_3_1::InputSource const&, bool, xercesc_3_1::XMLReader::RefFrom, xercesc_3_1::XMLReader::Types, xercesc_3_1::XMLReader::Sources, bool, unsigned long) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779==    by 0x4FE6758: xercesc_3_1::IGXMLScanner::scanReset(xercesc_3_1::InputSource const&) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779==    by 0x4FE0D03: xercesc_3_1::IGXMLScanner::scanDocument(xercesc_3_1::InputSource const&) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779==    by 0x50053B8: xercesc_3_1::XMLScanner::scanDocument(unsigned short const*) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779==    by 0x5008931: xercesc_3_1::XMLScanner::scanDocument(char const*) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779==    by 0x5027474: xercesc_3_1::AbstractDOMParser::parse(char const*) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779== 
==8779== LEAK SUMMARY:
==8779==    definitely lost: 11 bytes in 1 blocks
==8779==    indirectly lost: 0 bytes in 0 blocks
==8779==      possibly lost: 0 bytes in 0 blocks
==8779==    still reachable: 0 bytes in 0 blocks
==8779==         suppressed: 0 bytes in 0 blocks
==8779== 
==8779== For counts of detected and suppressed errors, rerun with: -v
==8779== Use --track-origins=yes to see where uninitialised values come from
==8779== ERROR SUMMARY: 5 errors from 2 contexts (suppressed: 2 from 2)

Answer 1

如果該庫確實在泄漏內存，則應解決該問題，因為該泄漏最終可能會影響應用程序。 內存泄漏的典型症狀包括掛起的進程或突然終止的進程（例如，當Linux內存不足殺手開始工作時）。

尋找另一個圖書館可能是可行的。 如果可以聯系到圖書館的維護者，最好引起他們的注意。 而且，如果它是開源的，那么對其進行跟蹤並提交修復程序將更加出色。

不過，這里要考慮的一件事。 Valgrind將標記最終未釋放為泄漏的任何內存。 該庫可能正在進行一次分配，例如創建單例。 如果是這樣，那么這確實不是問題。

因此，嘗試的事情：

• 跟蹤與庫的哪些交互會造成泄漏
• 確認這些互動實際上泄漏了-這意味着它們會隨着時間的推移分配多個
• 檢查庫中可能清除內存的操作
• 驗證庫的使用（例如，確保正在調用應調用的清理方法/函數）
• 聯系維護者
• 跟蹤並修復它（如果它是開源的）

指向未初始化字節的指針的錯誤不一定意味着有什么不對，只是該庫已分配了指針並且未將分配的內存設置為任何值。 如果程序遇到分段錯誤，則這些錯誤可能有助於跟蹤它們。 否則，這可能是完全正常的。 例如，該庫可能是預先分配的緩沖區，供以后使用。

再次，我會考慮向維護者提及這些錯誤，但是這些錯誤本身並不太令人擔憂。