Я пытаюсь найти утечки памяти из приложения C ++, над которым я работаю.Я выполнил valgrind с помощью следующей команды:
valgrind --leak-check=full --show-reachable=yes ./myApp <parameters>
Valgrind дает мне следующий вывод:
==32375==
==32375== HEAP SUMMARY:
==32375== in use at exit: 528 bytes in 11 blocks
==32375== total heap usage: 19,139 allocs, 19,128 frees, 429,638,284 bytes allocated
==32375==
==32375== 48 bytes in 1 blocks are still reachable in loss record 1 of 11
==32375== at 0x4C2A1E3: operator new(unsigned long) (vg_replace_malloc.c:334)
==32375== by 0xAC2AAE8: _GLOBAL__sub_I_binary_iarchive.cpp (in boostLocation/lib/libboost_serialization.so.1.67.0)
==32375== by 0x400F8F2: _dl_init (in /usr/lib64/ld-2.17.so)
==32375== by 0x4001159: ??? (in /usr/lib64/ld-2.17.so)
==32375== by 0x6: ???
==32375== by 0x1FFEFFFAE6: ???
==32375== by 0x1FFEFFFB38: ???
==32375== by 0x1FFEFFFB3B: ???
==32375== by 0x1FFEFFFB54: ???
==32375== by 0x1FFEFFFB57: ???
==32375== by 0x1FFEFFFB59: ???
==32375== by 0x1FFEFFFB5C: ???
==32375==
==32375== 48 bytes in 1 blocks are still reachable in loss record 2 of 11
==32375== at 0x4C2A1E3: operator new(unsigned long) (vg_replace_malloc.c:334)
==32375== by 0xAC2AB68: _GLOBAL__sub_I_binary_oarchive.cpp (in boostLocation/lib/libboost_serialization.so.1.67.0)
==32375== by 0x400F8F2: _dl_init (in /usr/lib64/ld-2.17.so)
==32375== by 0x4001159: ??? (in /usr/lib64/ld-2.17.so)
==32375== by 0x6: ???
==32375== by 0x1FFEFFFAE6: ???
==32375== by 0x1FFEFFFB38: ???
==32375== by 0x1FFEFFFB3B: ???
==32375== by 0x1FFEFFFB54: ???
==32375== by 0x1FFEFFFB57: ???
==32375== by 0x1FFEFFFB59: ???
==32375== by 0x1FFEFFFB5C: ???
==32375==
==32375== 48 bytes in 1 blocks are still reachable in loss record 3 of 11
==32375== at 0x4C2A1E3: operator new(unsigned long) (vg_replace_malloc.c:334)
==32375== by 0xAC2ABE8: _GLOBAL__sub_I_extended_type_info.cpp (in boostLocation/lib/libboost_serialization.so.1.67.0)
==32375== by 0x400F8F2: _dl_init (in /usr/lib64/ld-2.17.so)
==32375== by 0x4001159: ??? (in /usr/lib64/ld-2.17.so)
==32375== by 0x6: ???
==32375== by 0x1FFEFFFAE6: ???
==32375== by 0x1FFEFFFB38: ???
==32375== by 0x1FFEFFFB3B: ???
==32375== by 0x1FFEFFFB54: ???
==32375== by 0x1FFEFFFB57: ???
==32375== by 0x1FFEFFFB59: ???
==32375== by 0x1FFEFFFB5C: ???
==32375==
==32375== 48 bytes in 1 blocks are still reachable in loss record 4 of 11
==32375== at 0x4C2A1E3: operator new(unsigned long) (vg_replace_malloc.c:334)
==32375== by 0xAC2AC68: _GLOBAL__sub_I_extended_type_info_typeid.cpp (in boostLocation/lib/libboost_serialization.so.1.67.0)
==32375== by 0x400F8F2: _dl_init (in /usr/lib64/ld-2.17.so)
==32375== by 0x4001159: ??? (in /usr/lib64/ld-2.17.so)
==32375== by 0x6: ???
==32375== by 0x1FFEFFFAE6: ???
==32375== by 0x1FFEFFFB38: ???
==32375== by 0x1FFEFFFB3B: ???
==32375== by 0x1FFEFFFB54: ???
==32375== by 0x1FFEFFFB57: ???
==32375== by 0x1FFEFFFB59: ???
==32375== by 0x1FFEFFFB5C: ???
==32375==
==32375== 48 bytes in 1 blocks are still reachable in loss record 5 of 11
==32375== at 0x4C2A1E3: operator new(unsigned long) (vg_replace_malloc.c:334)
==32375== by 0xAC2ACE8: _GLOBAL__sub_I_polymorphic_iarchive.cpp (in boostLocation/lib/libboost_serialization.so.1.67.0)
==32375== by 0x400F8F2: _dl_init (in /usr/lib64/ld-2.17.so)
==32375== by 0x4001159: ??? (in /usr/lib64/ld-2.17.so)
==32375== by 0x6: ???
==32375== by 0x1FFEFFFAE6: ???
==32375== by 0x1FFEFFFB38: ???
==32375== by 0x1FFEFFFB3B: ???
==32375== by 0x1FFEFFFB54: ???
==32375== by 0x1FFEFFFB57: ???
==32375== by 0x1FFEFFFB59: ???
==32375== by 0x1FFEFFFB5C: ???
==32375==
==32375== 48 bytes in 1 blocks are still reachable in loss record 6 of 11
==32375== at 0x4C2A1E3: operator new(unsigned long) (vg_replace_malloc.c:334)
==32375== by 0xAC2AD68: _GLOBAL__sub_I_polymorphic_oarchive.cpp (in boostLocation/lib/libboost_serialization.so.1.67.0)
==32375== by 0x400F8F2: _dl_init (in /usr/lib64/ld-2.17.so)
==32375== by 0x4001159: ??? (in /usr/lib64/ld-2.17.so)
==32375== by 0x6: ???
==32375== by 0x1FFEFFFAE6: ???
==32375== by 0x1FFEFFFB38: ???
==32375== by 0x1FFEFFFB3B: ???
==32375== by 0x1FFEFFFB54: ???
==32375== by 0x1FFEFFFB57: ???
==32375== by 0x1FFEFFFB59: ???
==32375== by 0x1FFEFFFB5C: ???
==32375==
==32375== 48 bytes in 1 blocks are still reachable in loss record 7 of 11
==32375== at 0x4C2A1E3: operator new(unsigned long) (vg_replace_malloc.c:334)
==32375== by 0xAC2ADE8: _GLOBAL__sub_I_text_iarchive.cpp (in boostLocation/lib/libboost_serialization.so.1.67.0)
==32375== by 0x400F8F2: _dl_init (in /usr/lib64/ld-2.17.so)
==32375== by 0x4001159: ??? (in /usr/lib64/ld-2.17.so)
==32375== by 0x6: ???
==32375== by 0x1FFEFFFAE6: ???
==32375== by 0x1FFEFFFB38: ???
==32375== by 0x1FFEFFFB3B: ???
==32375== by 0x1FFEFFFB54: ???
==32375== by 0x1FFEFFFB57: ???
==32375== by 0x1FFEFFFB59: ???
==32375== by 0x1FFEFFFB5C: ???
==32375==
==32375== 48 bytes in 1 blocks are still reachable in loss record 8 of 11
==32375== at 0x4C2A1E3: operator new(unsigned long) (vg_replace_malloc.c:334)
==32375== by 0xAC2AE68: _GLOBAL__sub_I_text_oarchive.cpp (in boostLocation/lib/libboost_serialization.so.1.67.0)
==32375== by 0x400F8F2: _dl_init (in /usr/lib64/ld-2.17.so)
==32375== by 0x4001159: ??? (in /usr/lib64/ld-2.17.so)
==32375== by 0x6: ???
==32375== by 0x1FFEFFFAE6: ???
==32375== by 0x1FFEFFFB38: ???
==32375== by 0x1FFEFFFB3B: ???
==32375== by 0x1FFEFFFB54: ???
==32375== by 0x1FFEFFFB57: ???
==32375== by 0x1FFEFFFB59: ???
==32375== by 0x1FFEFFFB5C: ???
==32375==
==32375== 48 bytes in 1 blocks are still reachable in loss record 9 of 11
==32375== at 0x4C2A1E3: operator new(unsigned long) (vg_replace_malloc.c:334)
==32375== by 0xAC2AEE8: _GLOBAL__sub_I_void_cast.cpp (in boostLocation/lib/libboost_serialization.so.1.67.0)
==32375== by 0x400F8F2: _dl_init (in /usr/lib64/ld-2.17.so)
==32375== by 0x4001159: ??? (in /usr/lib64/ld-2.17.so)
==32375== by 0x6: ???
==32375== by 0x1FFEFFFAE6: ???
==32375== by 0x1FFEFFFB38: ???
==32375== by 0x1FFEFFFB3B: ???
==32375== by 0x1FFEFFFB54: ???
==32375== by 0x1FFEFFFB57: ???
==32375== by 0x1FFEFFFB59: ???
==32375== by 0x1FFEFFFB5C: ???
==32375==
==32375== 48 bytes in 1 blocks are still reachable in loss record 10 of 11
==32375== at 0x4C2A1E3: operator new(unsigned long) (vg_replace_malloc.c:334)
==32375== by 0xAC2AF68: _GLOBAL__sub_I_xml_iarchive.cpp (in boostLocation/lib/libboost_serialization.so.1.67.0)
==32375== by 0x400F8F2: _dl_init (in /usr/lib64/ld-2.17.so)
==32375== by 0x4001159: ??? (in /usr/lib64/ld-2.17.so)
==32375== by 0x6: ???
==32375== by 0x1FFEFFFAE6: ???
==32375== by 0x1FFEFFFB38: ???
==32375== by 0x1FFEFFFB3B: ???
==32375== by 0x1FFEFFFB54: ???
==32375== by 0x1FFEFFFB57: ???
==32375== by 0x1FFEFFFB59: ???
==32375== by 0x1FFEFFFB5C: ???
==32375==
==32375== 48 bytes in 1 blocks are still reachable in loss record 11 of 11
==32375== at 0x4C2A1E3: operator new(unsigned long) (vg_replace_malloc.c:334)
==32375== by 0xAC2AFE8: _GLOBAL__sub_I_xml_oarchive.cpp (in boostLocation/lib/libboost_serialization.so.1.67.0)
==32375== by 0x400F8F2: _dl_init (in /usr/lib64/ld-2.17.so)
==32375== by 0x4001159: ??? (in /usr/lib64/ld-2.17.so)
==32375== by 0x6: ???
==32375== by 0x1FFEFFFAE6: ???
==32375== by 0x1FFEFFFB38: ???
==32375== by 0x1FFEFFFB3B: ???
==32375== by 0x1FFEFFFB54: ???
==32375== by 0x1FFEFFFB57: ???
==32375== by 0x1FFEFFFB59: ???
==32375== by 0x1FFEFFFB5C: ???
==32375==
==32375== LEAK SUMMARY:
==32375== definitely lost: 0 bytes in 0 blocks
==32375== indirectly lost: 0 bytes in 0 blocks
==32375== possibly lost: 0 bytes in 0 blocks
==32375== still reachable: 528 bytes in 11 blocks
==32375== suppressed: 0 bytes in 0 blocks
==32375==
==32375== For counts of detected and suppressed errors, rerun with: -v
==32375== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Я знаю, что все еще достижимые «утечки» памяти не всегда являются большой проблемой, ноЯ все еще хочу избавиться от них.Кроме того, я не понимаю, откуда эти утечки.Похоже, они являются памятью, выделенной повышением в начале выполнения, над которым я не могу контролироватьПоскольку boost компилируется на моей машине, я попытался скомпилировать boost с помощью символов отладки, чтобы valgrind мог показать мне номера строк или более детальную трассировку стека, но это не сработало, и я получил точно такой же вывод, выполнив objdump --debugging файл .so дал мне много выходных данных, поэтому я считаю, что он содержит символы, но valgrind, похоже, не заботится.
Кто-то знает, откуда взялись эти распределения?Или как я мог бы получить больше информации из исходного кода Boost?
Дополнительный вопрос, у меня также есть утечки из потоков Boost, даже если поток фактически соединен и освобожден.Valgrind дает мне следующий след:
==1040== 624 bytes in 1 blocks are possibly lost in loss record 15 of 15
==1040== at 0x4C2B955: calloc (vg_replace_malloc.c:711)
==1040== by 0x40126B4: _dl_allocate_tls (in /usr/lib64/ld-2.17.so)
==1040== by 0x50B97AB: pthread_create@@GLIBC_2.2.5 (in /usr/lib64/libpthread-2.17.so)
==1040== by 0xA7381C9: boost::thread::start_thread_noexcept() (in boostLocation/lib/libboost_thread.so.1.67.0)
==1040== by 0x56336CA: start_thread (thread.hpp:179)
==1040== by 0x56336CA: boost::thread::thread<void (*)(<arguments>) (thread.hpp:435)
==1040== by 0x5630FA8: <my code, allocating then freeing a new boost::thread>
Я не потратил много времени на эту последнюю ошибку, но я все равно был бы рад получить больше информации от valgrind ...