Я написал длинную программу на C ++, которая отлично работает, в большинстве случаев и на машинах.
Используется:
- Версия Qt5 5.5.1
- (vl c) libvl c 2.2.7
- , работающая на Ubuntu 16.04,
- linux image 4.4.0-174-generi c
Но тестируем его на другом компьютере, когда основной l oop проходит почти 30 итераций ( каждая итерация занимает примерно 3 минуты.) система работает нестабильно и медленно.
Я провел тест с valgrind . Я могу прочитать резюме следующим образом.
> ==16327== LEAK SUMMARY:
> ==16327== definitely lost: 1,240 bytes in 10 blocks
> ==16327== indirectly lost: 11,373 bytes in 354 blocks
> ==16327== possibly lost: 13,741,198 bytes in 3,961 blocks
> ==16327== still reachable: 515,970,584 bytes in 138,649 blocks
> ==16327== of which reachable via heuristic:
> ==16327== length64 : 138,624 bytes in 294 blocks
> ==16327== newarray : 5,466 bytes in 189 blocks
> ==16327== suppressed: 0 bytes in 0 blocks
> ==16327== Reachable blocks (those to which a pointer was found) are not shown.
> ==16327== To see them, rerun with: --leak-check=full --show-leak-kinds=all
> ==16327==
> ==16327== For counts of detected and suppressed errors, rerun with: -v
> ==16327== Use --track-origins=yes to see where uninitialised values come from
> ==16327== ERROR SUMMARY: 10002390 errors from 2404 contexts (suppressed: 0 from 0)
Утечки появляются при создании объекта vl c.
vlc_main->vlcMedia_Player = libvlc_media_player_new(vlc_main->vlcInstance); // LEAK
libvlc_media_t *vlcMedia = libvlc_media_new_path(vlc_main->vlcInstance, _current_theme.theme_path.toUtf8().constData()); // LEAK
libvlc_media_player_set_media(vlc_main->vlcMedia_Player, vlcMedia);
libvlc_media_release(vlcMedia);
Это сводит меня с ума, потому что я не нашел, как бороться с libvl c code.
Итак, я скомпилировал с bdwg c Boehm-Demers-Weiser C / C ++ сборщик мусора.
После компиляции Valgrind все еще показывает мне утечку Резюме .
Я настроил:
echo GC_FIND_LEAK=1
и другие.
Но я все еще не уверен, что моя программа собирает мусор.