Существует ли приемлемый предел для утечек памяти?

Всегда? Никогда. Порядок всегда один и тот же: неопределенный (возможно, физический порядок хранения документов). Если вы не сортируете его.

20
задан Jim 27 October 2008 в 13:42
поделиться

11 ответов

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

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

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

BTW я не аффилирован с IBM всегда. Я только что использовал, Очищают экстенсивно и будет ручаться за его эффективность.

Редактирование: вот превосходная вводная статья , касающаяся контроля памяти. Это, Очищают конкретный, но обсуждение типов ошибок памяти очень интересно.

HTH.

аплодисменты,

Rob

17
ответ дан 29 November 2019 в 22:43
поделиться

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

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

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

РЕДАКТИРОВАНИЕ

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

11
ответ дан 29 November 2019 в 22:43
поделиться

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

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

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

11
ответ дан 29 November 2019 в 22:43
поделиться

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

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

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

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

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

8
ответ дан 29 November 2019 в 22:43
поделиться

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

7
ответ дан 29 November 2019 в 22:43
поделиться

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

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

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

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

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

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

2
ответ дан 29 November 2019 в 22:43
поделиться

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

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

1
ответ дан 29 November 2019 в 22:43
поделиться

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

2
ответ дан 29 November 2019 в 22:43
поделиться

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

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

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

6
ответ дан 29 November 2019 в 22:43
поделиться

Утечки памяти Firstable являются только серьезной проблемой, когда они растут со временем, иначе приложение просто выглядит немного больше с внешней стороны (очевидно, существует предел здесь также, следовательно 'серьезное'). Когда у Вас есть утечка, которая растет со временем, Вы могли бы быть в беде. Сколько проблемы зависит от обстоятельств все же. Если Вы знаете , куда память идет и может удостовериться, что у Вас всегда будет достаточно памяти для запущения программы и всего остального на той машине, Вы все еще несколько в порядке. Если Вы не знаете, куда память идет однако, я не поставил бы программу и продолжал бы рыть.

1
ответ дан 29 November 2019 в 22:43
поделиться

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

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

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

1
ответ дан 29 November 2019 в 22:43
поделиться
Другие вопросы по тегам:

Похожие вопросы: