Я пытаюсь проверить утечку памяти моей программы с помощью Valgrind.
Примечание: моя программа содержит FSM, который опрашивается каждые 200 мс. (упомяну это, потому что я думаю, что это может иметь что-тоделать с утечками)
Я выполнил следующую команду и создал файл журнала.
valgrind --leak-check=full --track-origins=yes --verbose --log-file=valgrind_test.log ./foo
Я вижу, что в моей программе много утечек, и 90% из них следуют тому же маршруту / пути, как указано ниже
==9890== 96 bytes in 1 blocks are possibly lost in loss record 2,341 of 2,707
==9890== at 0x4C30035: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==9890== by 0x66D96B0: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.5400.3)
==9890== by 0x69CB421: ??? (in /usr/lib64/libgobject-2.0.so.0.5400.3)
==9890== by 0x69CB5CA: ??? (in /usr/lib64/libgobject-2.0.so.0.5400.3)
==9890== by 0x69D1062: g_type_register_fundamental (in /usr/lib64/libgobject-2.0.so.0.5400.3)
==9890== by 0x6CBADD1: gst_fraction_get_type (gstvalue.c:7428)
==9890== by 0x6CBB0B5: _priv_gst_value_initialize (gstvalue.c:7527)
==9890== by 0x6C23B50: init_post (gst.c:777)
==9890== by 0x66E011F: g_option_context_parse (in /usr/lib64/libglib-2.0.so.0.5400.3)
==9890== by 0x6C2462E: gst_init_check (gst.c:427)
==9890== by 0x6C24676: gst_init (gst.c:471)
==9890== by 0x5546CC: main (foo.cpp:97)
Теперь, так как этот конкретный набор строк повторяется в журнале, я предполагаю, что опрос имеет какое-то отношение к этому, хотя я неконечно.
Я не нашел пути в журнале Valgrind, где блокированные / выделенные / полученные воспоминания не освобождаются / освобождаются.Это все сторонние (GStreamer) пути.Как мне проанализировать и устранить эти утечки?
Вопрос:
==9890== by 0x69CB421: ??? (in /usr/lib64/libgobject-2.0.so.0.5400.3)
Что это значит
-------------------------------------------------РЕДАКТИРОВАТЬ-------------------------------------------------------
обновлены сценарии для подавления ложных положительных случаев утечки glib mem
export G_DEBUG=gc-friendly
export G_SLICE=always-malloc
export GLIBCPP_FORCE_NEW=1
export GLIBCXX_FORCE_NEW=1
OPTS="-v --time-stamp=yes --tool=memcheck --leak-check=yes --leak-resolution=high --log-file=valgrind_test.log --suppressions=/path/to/glibc-2.supp --suppressions=/path/to/gst.supp"
valgrind $OPTS ./foo
И следующий полный файл журнала:
Полный журнал
==00:00:00:25.155 3241== LEAK SUMMARY:
==00:00:00:25.155 3241== definitely lost: 0 bytes in 0 blocks
==00:00:00:25.155 3241== indirectly lost: 0 bytes in 0 blocks
==00:00:00:25.155 3241== possibly lost: 96 bytes in 1 blocks
==00:00:00:25.155 3241== still reachable: 133,919 bytes in 1,457 blocks
==00:00:00:25.155 3241== of which reachable via heuristic:
==00:00:00:25.155 3241== length64 : 504 bytes in 12 blocks
==00:00:00:25.155 3241== newarray : 1,616 bytes in 21 blocks
==00:00:00:25.155 3241== suppressed: 831,853 bytes in 10,770 blocks
==00:00:00:25.155 3241== Reachable blocks (those to which a pointer was found) are not shown.
==00:00:00:25.155 3241== To see them, rerun with: --leak-check=full --show-leak-kinds=all
Итак, как я могу предотвратить эти потери?