Сама проблема поставлена тут - Об объектах-зомби и борьбе с ними
И вот в комментариях было написано (http://programmingmindstream.blogspot.ru/2014/11/blog-post_8.html?showComment=1415487831879#c6290262245505678584):
"Да, и ещё... FastMM4 в FullDebugMode достаточно уверенно ловит повторное освобождение объектов."
Несмотря на то, что в исходном посте я написал - "Сразу оговорюсь - я знаю про FastMem".
Что хочу сказать?
Чем лично для меня собственное решение "на коленке" - лучше?
Тем, что FastMM требует режима FullDebugMode , который "не так лёгок" (ну или я не умею его готовить) и выдавать всем пользователям подобное приложение - накладно. Оно будет "мешать им работать". Да и зачастую всем - и не нужно.
Т.е. можно конечно гонять "синтетические тесты", но нет полной гарантии, что оно проявится ровно так как у конечного пользователя.
А вот "собственный" менеджер памяти можно включить/выключить практически "на лету", например меняя флаг в ini-файле или вообще по срабатыванию какого-нибудь триггера в бизнес-логике.
Вот собственно и всё. Универсальное решение - оно конечно хорошо. Но зато не универсальное решение поддаётся более тонкой настройке в конкретных условиях.
Ну и собственно - зная про"мой менеджер памяти" можно "примерно представить" - как устроен FastMM.
Что - зачастую - полезно. "Назад к основам" так сказать.
Ну и кстати ещё из "серии работы с памятью" - Коротко. Об оптимизации потребления памяти под xCode. Затравочка.
И вот в комментариях было написано (http://programmingmindstream.blogspot.ru/2014/11/blog-post_8.html?showComment=1415487831879#c6290262245505678584):
"Да, и ещё... FastMM4 в FullDebugMode достаточно уверенно ловит повторное освобождение объектов."
Несмотря на то, что в исходном посте я написал - "Сразу оговорюсь - я знаю про FastMem".
Что хочу сказать?
Чем лично для меня собственное решение "на коленке" - лучше?
Тем, что FastMM требует режима FullDebugMode , который "не так лёгок" (ну или я не умею его готовить) и выдавать всем пользователям подобное приложение - накладно. Оно будет "мешать им работать". Да и зачастую всем - и не нужно.
Т.е. можно конечно гонять "синтетические тесты", но нет полной гарантии, что оно проявится ровно так как у конечного пользователя.
А вот "собственный" менеджер памяти можно включить/выключить практически "на лету", например меняя флаг в ini-файле или вообще по срабатыванию какого-нибудь триггера в бизнес-логике.
Вот собственно и всё. Универсальное решение - оно конечно хорошо. Но зато не универсальное решение поддаётся более тонкой настройке в конкретных условиях.
Ну и собственно - зная про"мой менеджер памяти" можно "примерно представить" - как устроен FastMM.
Что - зачастую - полезно. "Назад к основам" так сказать.
Ну и кстати ещё из "серии работы с памятью" - Коротко. Об оптимизации потребления памяти под xCode. Затравочка.
«...Тем, что FastMM требует режима FullDebugMode , который "не так лёгок" (ну или я не умею его готовить) и выдавать всем пользователям подобное приложение - накладно. Оно будет "мешать им работать". За и зачастую всем - и не нужно.»
ОтветитьУдалить-- См. FastMM4Options.inc:
«{Combines the FullDebugMode, LoadDebugDLLDynamically and
DoNotInstallIfDLLMissing options. Consequently FastMM will only be installed
(In FullDebugMode) when the FastMM_FullDebugMode.dll file is available. This
is useful when the same executable will be distributed for both debugging as
well as deployment.}
{.$define FullDebugModeWhenDLLAvailable}»
-- позволяет включать FullDebugMode только в случае наличия в пределах доступности FASTMM_FullDebugMode.dll.
Т.е. почти "на лету" - после включения в выключенном состоянии потребуется перезапуск приложения, чтобы "подхватить" DLL, скопированный в результате включения, например, в рабочий каталог программы.
Спасибо.
УдалитьНо учитывая, что "есть своё" - вряд ли когда попробую.
Хотя - кто знает.
Но всё равно - спасибо.
IMHO требование проверки программистом проделанной работы в режиме FullDebugMode - очень удачный паттерн, позволяющий выявить множество проблем, и не только в своём коде.
ОтветитьУдалитьСогласен.
УдалитьНо можно не "требовать", а "поставить перед фактом". Внедрив собственный менеджер. Без всяких "пасов руками" типа внешних DLL.
УдалитьНу и собственно - зная про"мой менеджер памяти" можно "примерно представить" - как устроен FastMM.
УдалитьЧто - зачастую - полезно. "Назад к основам" так сказать. http://russian.joelonsoftware.com/Articles/BacktoBasics.html
И опять - согласен.
УдалитьСегодня я столкнулся с тем, что "люди не контроллируют утечки памяти".
Не на работе. На работе - я бы быстро это увидел бы.