#c #memory-leaks #valgrind #freeze #gdbserver
#c #утечки памяти #valgrind #замораживание #gdbserver
Вопрос:
Я использую valgrind впервые и пытаюсь использовать его для обнаружения утечки памяти в моей программе (https://github.com/ardera/flutter-pi ). Приложение представляет собой встроенное приложение с графическим интерфейсом и взаимодействует с некоторыми устройствами ядра напрямую. Архитектура, на которой я ее выполняю, — Linux на ARMv7, hardfp ABI.
Однако после того, как я использую valgrind для запуска своей программы, процесс полностью зависает, потребляя 100% ЦП на одном ядре процессора. Использование памяти остается постоянным, пока она зависает. (Кстати, использование памяти значительно ниже 100%)
Я не могу использовать Ctrl C для ее завершения, отправка SIGTERM через htop не работает, команды vgdb, которые я пробовал (например, vgdb v.info scheduler или просто vgdb v.info ), не работают, потому что valgrind gdbserver не отправляет ответ в канал. Если я использую --vgdb=yes --vgdb-error=1 и подключаюсь к valgrind gdbserver через gdb , я даже не могу там нажать Ctrl C. Я также должен уничтожить ее с помощью SIGKILL.
Обычно в стандартном режиме должно быть некоторое протоколирование, и через 5 секунд на моем экране появится графический интерфейс. Если я использую valgrind, после ожидания в течение 15 минут из моей программы вообще не будет входа в стандартный вывод, а также не будет графического интерфейса.
Однако Valgrind что-то выводит, в основном связанное с доступом к неинициализированной памяти. (Использование неинициализированного значения, условный переход или перемещение зависит от неинициализированного значения и т.д.) Полный вывод находится здесь.
Кто-нибудь знает, что вызывает это? Это ошибка в valgrind или в моем коде? Кто-нибудь знает альтернативные способы обнаружения утечек памяти? Если это ошибка в моем коде, как мне ее найти?
Комментарии:
1. предупреждение valgrind интерпретирует двоичный файл, поэтому время выполнения больше, чем исходное. Из этого у вас есть UB, поэтому по определению выполнение может быть не таким, как из valgrind. Итак, сначала удалите весь UB, чтобы не было никаких сообщений от valgrind , и выполните «нормальное» выполнение перед поиском утечек памяти
2. Известны проблемы с использованием Valgrind, то есть при использовании определенных встроенных вызовов Valgrind. На этом сайте перечислены некоторые из них. Ищите такие слова, как сбой.
3. Обратите внимание, что условный переход, который зависит от неинициализированного значения, может легко проявиться как «замораживание», например, если это происходит для управления условием завершения цикла. Valgrind может привести к тому, что ваше неинициализированное значение будет отличаться от значения, которое оно имело бы в вашей обычной среде.
4. Я только что отладил их, и все неопределенное поведение возникало во время загрузки, когда ld-linux.so загружается мой двоичный файл. (Я отследил стек вызовов при каждой ошибке, и _start был общим знаменателем.)
5. Valgrind 9-летней давности 3.7.0, серьезно? Попробуйте использовать Valrind 3.16.1. Это может решить ваши проблемы с dwarf debuginfo и ld.so .