Valgrind在應用程序運行時打印帶有錯誤的摘要，但表示完成時不會發生泄漏

Question

我試圖用valgrind查明應用程序的內存錯誤。

Valgrind顯示了一個奇怪的行為，到目前為止我還沒有觀察到它：Valgrind在應用程序運行時打印帶有錯誤的摘要但是說完所有釋放都沒有泄漏

不幸的是，我無法透露它背后的應用程序源代碼，但我可以這么說

• 該應用程序是多線程的
• 該應用程序使用zmq
• 該應用程序是用C ++編寫的（11）
• 該應用程序是使用gcc-4.9.2構建的
• 在Debian上運行：Debian 3.16.0-4-amd64＃1 SMP Debian 3.16.51-3（2017-12-13）x86_64 GNU / Linux（來自uname -a）
• 我已經下載了valgrind 3.13.0源快照，並使用相同的編譯器在同一系統上構建它

也許有人暗示或暗示這里發生了什么？ 我不確定該程序是否正常運行。 在調試或測試時，我發現應用程序沒有問題，即附加了gdb，應用程序執行正常關閉。

這是發生的事情：

valgrind ./<application>


==11431== Memcheck, a memory error detector
==11431== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==11431== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==11431== Command: ./<<application>>
==11431== 

                     << output from application being analyzed >>

==11446== 
==11446== HEAP SUMMARY:
==11446==     in use at exit: 36,963,243 bytes in 12,456 blocks
==11446==   total heap usage: 112,306 allocs, 99,850 frees, 167,728,353 bytes allocated
==11446== 
==11446== LEAK SUMMARY:
==11446==    definitely lost: 13,419 bytes in 163 blocks
==11446==    indirectly lost: 24,368 bytes in 486 blocks
==11446==      possibly lost: 5,741 bytes in 106 blocks
==11446==    still reachable: 36,919,715 bytes in 11,701 blocks
==11446==                       of which reachable via heuristic:
==11446==                         stdstring          : 211,119 bytes in 5,162 blocks
==11446==         suppressed: 0 bytes in 0 blocks
==11446== Rerun with --leak-check=full to see details of leaked memory
==11446== 
==11446== For counts of detected and suppressed errors, rerun with: -v
==11446== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==11448== 
==11448== HEAP SUMMARY:
==11448==     in use at exit: 37,699,870 bytes in 12,837 blocks
==11448==   total heap usage: 115,854 allocs, 103,017 frees, 168,950,644 bytes allocated
==11448== 
==11448== LEAK SUMMARY:
==11448==    definitely lost: 14,252 bytes in 155 blocks
==11448==    indirectly lost: 24,864 bytes in 498 blocks
==11448==      possibly lost: 5,749 bytes in 106 blocks
==11448==    still reachable: 37,655,005 bytes in 12,078 blocks
==11448==                       of which reachable via heuristic:
==11448==                         stdstring          : 214,732 bytes in 5,238 blocks
==11448==         suppressed: 0 bytes in 0 blocks
==11448== Rerun with --leak-check=full to see details of leaked memory
==11448== 
==11448== For counts of detected and suppressed errors, rerun with: -v
==11448== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==11449== 
==11449== HEAP SUMMARY:
==11449==     in use at exit: 37,817,537 bytes in 12,875 blocks
==11449==   total heap usage: 119,125 allocs, 106,250 frees, 170,106,138 bytes allocated
==11449== 
==11449== LEAK SUMMARY:
==11449==    definitely lost: 12,013 bytes in 146 blocks
==11449==    indirectly lost: 24,864 bytes in 498 blocks
==11449==      possibly lost: 5,749 bytes in 106 blocks
==11449==    still reachable: 37,774,911 bytes in 12,125 blocks
==11449==                       of which reachable via heuristic:
==11449==                         stdstring          : 215,361 bytes in 5,252 blocks
==11449==                         multipleinheritance: 992 bytes in 1 blocks
==11449==         suppressed: 0 bytes in 0 blocks
==11449== Rerun with --leak-check=full to see details of leaked memory
==11449== 
==11449== For counts of detected and suppressed errors, rerun with: -v
==11449== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

               << output from application being analyzed, app is shutting down now >>

==11431== 
==11431== HEAP SUMMARY:
==11431==     in use at exit: 0 bytes in 0 blocks
==11431==   total heap usage: 343,376 allocs, 343,376 frees, 329,511,726 bytes allocated
==11431== 
==11431== All heap blocks were freed -- no leaks are possible
==11431== 
==11431== For counts of detected and suppressed errors, rerun with: -v
==11431== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Answer 1

@Vincent Saulue-Laborde，謝謝你引導我走向正確的方向。

來自Poco::Process::launch調用后面的fork的雙重摘要結果。

這是一個最小的例子 - 注意這個debian上沒有“route”（但是，當為實際的arm-target交叉編譯這個應用程序時）：

#include <iostream>
#include <Poco/Process.h>
#include <Poco/Pipe.h>

int main()
{
    Poco::Pipe out_pipe;
    if (Poco::Process::launch("route", {}, 0, &out_pipe, 0).wait() == EXIT_SUCCESS) { }
    return 0;
}

用valgrind運行它並添加switch --trace-children：

    valgrind --leak-check=full --trace-children=yes ./hello_world
==1814== Memcheck, a memory error detector
==1814== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==1814== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==1814== Command: ./hello_world
==1814== 
==1815== 
==1815== HEAP SUMMARY:
==1815==     in use at exit: 10,612 bytes in 102 blocks
==1815==   total heap usage: 113 allocs, 11 frees, 13,028 bytes allocated
==1815== 
==1815== 16 bytes in 1 blocks are definitely lost in loss record 3 of 102
==1815==    at 0x4C28215: operator new(unsigned long) (vg_replace_malloc.c:334)
==1815==    by 0x7B40147: Poco::ProcessImpl::launchByForkExecImpl(std::string const&, std::vector<std::string, std::allocator<std::string> > const&, std::string const&, Poco::Pipe*, Poco::Pipe*, Poco::Pipe*, std::map<std::string, std::string, std::less<std::string>, std::allocator<std::pair<std::string const, std::string> > > const&) (in /home/user/dev/zedboard/build/deps/host/Debug/lib/libPocoFoundation.so.60)
==1815==    by 0x7B41648: Poco::Process::launch(std::string const&, std::vector<std::string, std::allocator<std::string> > const&, Poco::Pipe*, Poco::Pipe*, Poco::Pipe*) (in /home/user/dev/zedboard/build/deps/host/Debug/lib/libPocoFoundation.so.60)
==1815==    by 0x401E09: main (main.cpp:8)
==1815== 
==1815== LEAK SUMMARY:
==1815==    definitely lost: 16 bytes in 1 blocks
==1815==    indirectly lost: 0 bytes in 0 blocks
==1815==      possibly lost: 0 bytes in 0 blocks
==1815==    still reachable: 10,596 bytes in 101 blocks
==1815==                       of which reachable via heuristic:
==1815==                         stdstring          : 3,123 bytes in 87 blocks
==1815==         suppressed: 0 bytes in 0 blocks
==1815== Reachable blocks (those to which a pointer was found) are not shown.
==1815== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==1815== 
==1815== For counts of detected and suppressed errors, rerun with: -v
==1815== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
==1814== 
==1814== HEAP SUMMARY:
==1814==     in use at exit: 0 bytes in 0 blocks
==1814==   total heap usage: 116 allocs, 116 frees, 13,837 bytes allocated
==1814== 
==1814== All heap blocks were freed -- no leaks are possible
==1814== 
==1814== For counts of detected and suppressed errors, rerun with: -v
==1814== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

也許我應該為Poco提交一個錯誤...

Answer 2

您正在查看子進程的報告。 每個報告都有等號之間的進程ID。 具有內存泄漏的報告與最終報告的報告不同。

當子進程啟動但不能通過執行目標可執行文件從valgrind的視圖中消失時，它必須終止。 不幸的是，valgrind然后打印一個內存泄漏報告，其泄漏在庫代碼中是不可避免的。

如果可能的話，使用--child-silent-after-fork=yes啟動valgrind是一個非常--child-silent-after-fork=yes解決方法， --child-silent-after-fork=yes會使分叉的子進程的所有報告--child-silent-after-fork=yes 。 如果不需要調查內存泄漏的子進程，這當然只是一個有效的選項。