Как проверить на утечки памяти?

Question

У нас есть приложение с сотнями возможных действий пользователя, и мы думаем о том, как улучшить тестирование утечки памяти.

В настоящее время происходит так: при тестировании программного обеспечения вручную, если выясняется, что наше приложение потребляет слишком много памяти, мы используем инструмент памяти, находим причину и устраняем ее. Это довольно медленный и неэффективный процесс: проблемы обнаруживаются поздно, и он зависит от доброй воли одного разработчика.

Как мы можем улучшить это?

• Внутренне проверить, что некоторые действия (например, «закрыть файл») действительно восстанавливают часть памяти и регистрируют ее?
• Утверждение состояния памяти в наших модульных тестах (но, похоже, это было бы утомительным занятием)?
• Вручную регулярно проверять это время от времени?
• Включить эту проверку каждый раз, когда создается новая пользовательская история?

Answer 1

Какой язык?

Я бы использовал такой инструмент, как Valgrind, попробовал бы полностью выполнить программу и посмотреть, что она сообщает.

Answer 2

Первая линия обороны:

• контрольный список с общей памятью связанные с распределением ошибки для Разработчики
• правила кодирования

вторая линия обороны:

• код отзыва
• статический анализ кода (как часть процесса сборки)
• инструменты профилирования памяти

Если вы работаете с неуправляемым языком (например, C / C ++), вы можете эффективно обнаруживать большинство утечек памяти, угоняя функции управления памятью. Например, вы можете отслеживать все распределения / освобождения памяти.

Answer 3

Мне кажется, что суть проблемы не столько в обнаружении утечек памяти, сколько в знании, когда их проверять. Вы говорите, что у вас много пользовательских действий, но вы не говорите, что последовательности пользовательских действий значимы. Если вы можете генерировать значимые последовательности наугад, я бы поспорил на случайное тестирование. На случайных тестах вы бы измеряли

• Покрытие кода (с gcov или valgrind)
• Использование памяти (с valgrind)
• Освещение самих действий пользователя

Под «освещением действий пользователя» я подразумеваю следующие утверждения:

• Для каждой пары действий A и B, если существует значимая последовательность действий, в которой сразу за A следует B, то мы проверили такую ​​последовательность.

Если это не так, то вы можете спросить, какая доля пар A и B это правда.

Если у вас есть циклы ЦП, чтобы позволить себе это, вы, вероятно, также выиграете от запуска valgrind или другого инструмента проверки памяти перед каждой фиксацией в вашем хранилище исходного кода или во время ночной сборки. .

Автоматизировать!

Answer 4

Замените новые и , удалите своими пользовательскими версиями и зарегистрируйте каждый акт распределения / освобождения.

Говоря в целом (не о тестировании, а о том, чтобы бороться с проблемой в ее происхождении), smartpointers помогают избежать этой проблемы. К счастью, стандарт C ++ 11 предоставляет новые удобные классы интеллектуальных указателей (shared_ptr, unique_ptr).

Answer 5

В моей компании мы запрограммировали бесконечный путь действий для нашего приложения. Java сборщик мусора должен очистить все неиспользуемые карты и список и что-то в этом роде. Поэтому мы позволяем приложению запускаться с бесконечного пути действия и смотреть, растет ли объем используемой памяти.

Проверяя, какие поля не удалены, вы можете использовать JProfiler for Java.