Есть ли приемлемый предел для утечек памяти?

Ответ 1

Будьте осторожны, чтобы Valgrind не собирал ложные срабатывания в своих измерениях.

Многие наивные реализации анализаторов памяти теряют память как утечку, когда это не так.

Возможно, прочитайте некоторые статьи во внешнем разделе ссылок статьи в статье Википедии о очистке. Я знаю, что документация, поставляемая с Purify, описывает несколько сценариев, в которых вы обнаруживаете ложные срабатывания при попытке обнаружить утечки памяти, а затем описываете методы, используемые Purify, чтобы обойти проблемы.

Кстати, я никоим образом не связан с IBM. Я просто использовал Purify широко и ручаюсь за его эффективность.

Изменить: здесь отличная вступительная статья, в которой описывается мониторинг памяти. Это Purify specific, но обсуждение типов ошибок памяти очень интересно.

НТН.

веселит,

Rob

Ответ 2

Вы должны быть осторожны с определением "утечка памяти". То, что выделяется один раз при первом использовании и освобождается при выходе из программы, иногда будет отображаться детектором утечки, потому что он начал подсчитывать перед первым использованием. Но это не утечка (хотя это может быть плохой дизайн, поскольку это может быть какой-то глобальный).

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

Мне редко было слишком сложно попасть в нуль по этой метрике, что эквивалентно наблюдению за использованием ползучей памяти, а не потерянных блоков. У меня была одна библиотека, где она так нервничала, с кешами и интернетом, и еще кое-что, что я просто три раза запускал свой тестовый пакет и игнорировал любые "утечки", которые не встречались в кратных трех блоках. Я все еще поймал все или почти все настоящие утечки, и проанализировал хитрые сообщения, как только у меня получился низкий висящий плод. Конечно, недостатки использования набора тестов для этой цели заключаются в следующем: (1) вы можете использовать только те части, которые не требуют нового процесса, и (2) большинство утечек, которые вы обнаружите, являются ошибкой тестового кода, а не код библиотеки...

Ответ 3

Жизнь с утечками памяти (и другие неосторожные проблемы) в лучшем случае (на мой взгляд) очень плохое программирование. В худшем случае это делает программное обеспечение непригодным.

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

Избегайте неряшливого программирования - там уже достаточно плохих программистов - мир не нуждается в другом.

ИЗМЕНИТЬ

Я согласен - многие инструменты могут предоставлять ложные срабатывания.

Ответ 4

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

Вам нужно протестировать приложение примерно на час, а затем вычислить пропущенную память. Таким образом, вы получите пропущенное значение байта/минуты памяти.

Теперь вам нужно будет оценить среднюю длину сеанса вашей программы. Например, для notepad.exe 15 минут звучат как хорошая оценка для меня.

Если ( средняя продолжительность сеанса) * (пропущенные байты/минута) > 0,3 * (объем памяти, обычно занятый вашим процессом), то вам, вероятно, следует предпринять дополнительные усилия для уменьшения утечек памяти. Я просто составил 0,3, использую здравый смысл, чтобы определить ваш приемлемый порог.

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

Ответ 5

Для настольного приложения небольшие утечки памяти не представляют реальной проблемы. Для служб (серверов) утечки памяти не принимаются.

Ответ 6

Большинство ОС (включая Windows) возвращают всю выделенную память программы, когда программа выгружается. Это включает в себя любую память, которую сама программа могла потерять.

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

Так что действительно вопрос заключается не в том, что вы просачиваете какую-либо память, это если вы постоянно протекаете ее во время выполнения вашей программы. Если вы используете свою программу какое-то время, и независимо от того, что вы делаете, она останется на 120 байт, а не увеличится, я бы сказал, что вы отлично поработали. Двигайтесь дальше.

Ответ 7

Это зависит от вашего приложения. Некоторая утечка может быть неизбежной (из-за времени, необходимого для определения сроков утечки). До тех пор, пока ваше приложение может работать столько, сколько вам нужно, и не принимать сумасшедшего объема памяти за это время, возможно, хорошо.

Ответ 8

Это похоже на то, что разработчики SDL не используют Valgrind, но я в основном забочусь только о потерянных 120 байтах.

Имея это в виду, я запускал свои программы Hello World через Valgrind, чтобы поймать любые утечки, и хотя я удалил все, кроме самых основных операторов SDL_Init() и SDL_Quit(), Valgrind все еще сообщает 120 байт потерян и 77k еще доступно.

Ну, с Valgrind, "все еще доступная память" часто не является просочившейся памятью, особенно в такой простой программе. Я могу с уверенностью сказать, что в SDL_Quit() в основном нет выделения, поэтому "утечки" - это просто структуры, выделенные один раз SDL_Init().

Попробуйте добавить полезную работу и посмотреть, увеличиваются ли эти суммы; попробуйте сделать цикл полезной работы (например, создать и уничтожить некоторую структуру SDL) и посмотреть, растет ли количество утечек с количеством итераций. В последнем случае вы должны проверить трассировку стека утечек и исправить их.

В противном случае те 77k утечки считаются "памятью, которая должна быть освобождена на конце программы, но для которой они полагаются на ОС, чтобы освободить ее.

Итак, на самом деле, меня больше беспокоят эти 120 байт, если они не являются ложными срабатываниями, и их обычно мало. Ложные срабатывания с Valgrind - это в основном случаи, когда предполагается использование неинициализированной памяти (например, потому что это действительно дополнение).

Ответ 9

Согласно комментариям Роба Уэллса о Purify, загрузите и попробуйте другие инструменты. Я использую BoundsChecker и AQTime и видел разные ложные срабатывания в течение многих лет. Обратите внимание, что утечка памяти также может быть в стороннем компоненте, который вы можете исключить из анализа. Например, у MFC было несколько утечек памяти в версиях первого вида.

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

Ответ 10

Первичные утечки памяти - это только серьезная проблема, когда они растут со временем, иначе приложение просто выглядит немного больше снаружи (очевидно, здесь есть предел, а значит, и "серьезный" ). Когда у вас есть утечка, которая растет со временем, у вас могут быть проблемы. Однако, насколько сложно, зависит от обстоятельств. Если вы знаете, куда идет память, и вы можете убедиться, что у вас всегда будет достаточно памяти для запуска программы, и все остальное на этой машине вы все равно будете в порядке. Если вы не знаете, где находится память, я бы не отправил программу и продолжал копать.

Ответ 11

В SDL в Linux, в частности, есть некоторые утечки в базовой библиотеке окон X. Вы ничего не можете с этим сделать (если вы не захотите исправить сама библиотека, которая, вероятно, не для слабонервных).

Вы можете использовать механизм подавления valgrind (см. -suppressions and -gen-suppressionions на странице man valgrind), чтобы сказать, чтобы вы не беспокоили вас этими ошибками.

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