Написал программу с использованием MFC. Утечек памяти, связанных с неудалением выделенной через new или malloc памяти там точно нет, связанных с COM вроде бы тоже (проверял Visual Leak Detector'ом). Заказчик пожаловался на утечки, проявляющиеся в виде возрастания "съеденной" приложением памяти в Диспетчере задач. Стал проверять. Увидел, что показатель растет при открытии диалогов программы (это понятно), чуть-чуть иногда возрастает по непонятной причине (причем, видимо, связанной с интерфейсом, т.к. при закрытых диалогах ничего такого не наблюдалось), а через какое-то время тестирования показатель резко уменьшился вдвое.
Соответственно, вопросы:
1) Как могут получаться утечки в MFC, если используются статические объекты, а динамические корректно удаляются?
2) Есть ли в MFC какой-нибудь механизм вроде уборщика мусора, которым можно объяснить резкое уменьшение используемой памяти?

Здравствуйте, Aracon, Вы писали:

A>Написал программу с использованием MFC. Утечек памяти, связанных с неудалением выделенной через new или malloc памяти там точно нет, связанных с COM вроде бы тоже (проверял Visual Leak Detector'ом).
То, что тулы их не нахоят ещё не явл. док-вом что их нет. Хотя, в случае MFC утечки памяти, связанных с неудалением выделенной через new или malloc пропустить почти невозможно. Утечки COM и BoundsChecker легко не заметит, тем более Visual Leak Detector. Если есть СОМ (вернее любой third-party) — утечки могут быть в нём.
Ещё бывают GDI leaks.

Заказчик пожаловался на утечки, проявляющиеся в виде возрастания "съеденной" приложением памяти в Диспетчере задач. Стал проверять. Увидел, что показатель растет при открытии диалогов программы (это понятно), чуть-чуть иногда возрастает по непонятной причине (причем, видимо, связанной с интерфейсом, т.к. при закрытых диалогах ничего такого не наблюдалось), а через какое-то время тестирования показатель резко уменьшился вдвое.
Ну и что? По вашему если кол-во используемой памяти не константно — значит есть утечки? Смотрите на люб. другую программу — увидите тоже самое. Сверните своё окно — вообще удивитесь.

A>Соответственно, вопросы:
A>1) Как могут получаться утечки в MFC, если используются статические объекты, а динамические корректно удаляются?
Тогда — не могут получаться.

A>2) Есть ли в MFC какой-нибудь механизм вроде уборщика мусора, которым можно объяснить резкое уменьшение используемой памяти?
Нету, но есть своп-файл ОС.

Здравствуйте, Aracon, Вы писали:

А к колонке GDI-Objects они пока еще не доцепились? Хотя она по умолчанию выключена
Больше чем ты уже сделал по-моему ничего сделать для поиска утечек памяти нельзя.
Можешь еще посмотреть триал MemoryValidator-a http://www.softwareverify.com/download_eval.php
У него большой плюс — он работает с realease, так что можешь вредному клиенту показать, если там все чисто.

Про сборщик мусора v MFC я никогда не слышал.

>а через какое-то время тестирования показатель резко уменьшился вдвое.
Тупой вопрос: может быть это связано с интервалом обновления самого task manager-а?
Там можно выставлять частоту обновления — если поставить на ручное обновление, то сможешь смотреть хоть после каждого оператора в программе в отдельности.

Здравствуйте, Аноним, Вы писали:

skip

A>>2) Есть ли в MFC какой-нибудь механизм вроде уборщика мусора, которым можно объяснить резкое уменьшение используемой памяти?
А>Нету, но есть своп-файл ОС.

А вот и неправда, есть
Правда, полноценным уборщиком мусора этот механизм назвать нельзя. Но тем не менее, в MFC есть куча объектов, за удаление которых отвечает сама библиотека.
Если интересны подробности: изучайте функции CWinApp::OnIdle, FromHandle и DeleteTempMap (эти методы есть у окон, меню и GDI-оберток).

Здравствуйте, Aracon, Вы писали:

A>Написал программу с использованием MFC. Утечек памяти, связанных с неудалением выделенной через new или malloc памяти там точно нет, связанных с COM вроде бы тоже (проверял Visual Leak Detector'ом). Заказчик пожаловался на утечки, проявляющиеся в виде возрастания "съеденной" приложением памяти в Диспетчере задач. Стал проверять. Увидел, что показатель растет при открытии диалогов программы (это понятно), чуть-чуть иногда возрастает по непонятной причине (причем, видимо, связанной с интерфейсом, т.к. при закрытых диалогах ничего такого не наблюдалось), а через какое-то время тестирования показатель резко уменьшился вдвое.
A>Соответственно, вопросы:
A>1) Как могут получаться утечки в MFC, если используются статические объекты, а динамические корректно удаляются?
A>2) Есть ли в MFC какой-нибудь механизм вроде уборщика мусора, которым можно объяснить резкое уменьшение используемой памяти?

А можно озвучить полученные значения? Из-за чего весь сыр бор. Может там всего пару мегабайт и никаких побочных эффектов типа бесконечного съедания памяти не наблюдается. Как долго может работать программа? Сервис? или простое приложение?

Здравствуйте, Aracon, Вы писали:

A>Написал программу с использованием MFC. Утечек памяти, связанных с неудалением выделенной через new или malloc памяти там точно нет, связанных с COM вроде бы тоже (проверял Visual Leak Detector'ом). Заказчик пожаловался на утечки, проявляющиеся в виде возрастания "съеденной" приложением памяти в Диспетчере задач. Стал проверять. Увидел, что показатель растет при открытии диалогов программы (это понятно), чуть-чуть иногда возрастает по непонятной причине (причем, видимо, связанной с интерфейсом, т.к. при закрытых диалогах ничего такого не наблюдалось), а через какое-то время тестирования показатель резко уменьшился вдвое.

Так ведёт себя любое приложение. Сейчас, вот, пишу в Опере. Занимает 50МБ. Нажал "Свернуть окно" стала занимать 4МБ.

Это не ваше приложение с меморили ликами, это так в виндах организована буферизация видео-информации десктопа.

А>Ещё бывают GDI leaks.
А это как?

Здравствуйте, Aracon, Вы писали:

A>А это как?

А это если создавать, но не уничтожать объекты GDI — шрифты, перья, кисти, регионы, etc.

Здравствуйте, Андрей, Вы писали:

А>А вот и неправда, есть
А>Правда, полноценным уборщиком мусора этот механизм назвать нельзя. Но тем не менее, в MFC есть куча объектов, за удаление которых отвечает сама библиотека.
>>Его действия вы вряд ли сможете пронаблюдать в таск менеджере. В данном случае речь скорее всего идёт о нормальном управлении памятью со стороны ОС, сбросом неиспользуемой в своп.
А>Если интересны подробности: изучайте функции CWinApp::OnIdle, FromHandle и DeleteTempMap (эти методы есть у окон, меню и GDI-оберток).
Знаете, совсем не интересно. MFC — это такое убожество, что тратить время на его изучение в деталях совсем не хочется. Да он и доживает-то последние дни: библиотека в первую очередь гуёвая, а гуй теперь на .НЕТ делают.
Я недавно портировал MFC аппликацию на wxWidgets, который тоже не верх элегантности, но получил чуство глубокого удовлетворения человека небезуспешно почистившего авгиевы конюшни.
А аппликация теперь и на линухе работает.

Здравствуйте, febus, Вы писали:

F>Про сборщик мусора v MFC я никогда не слышал.

Да есть там нечто подобное — например когда вы просите указатель на окно Cwnd* GetDlgItem(...) — вы получаете указатель на объект окна что то с ним делаете и далее не делаете delete, за вас это демает сборщик мусора который работает при простое приложения.

Здравствуйте, Aracon, Вы писали:

A>1) Как могут получаться утечки в MFC, если используются статические объекты, а динамические корректно удаляются?
A>2) Есть ли в MFC какой-нибудь механизм вроде уборщика мусора, которым можно объяснить резкое уменьшение используемой памяти?

Есть еще DevPartner — программа, которая интегрируется со студией и служит для поиска ошибок, утечек и т.д.
Возможно она поможет.

Здравствуйте, Аноним, Вы писали:

А>Знаете, совсем не интересно. MFC — это такое убожество, что тратить время на его изучение в деталях совсем не хочется. Да он и доживает-то последние дни: библиотека в первую очередь гуёвая, а гуй теперь на .НЕТ делают.

Хорошо, что ты хоть наш любимый С++ не обругал. Я сам первый месяц MFC не любил, а потом смирился, даже нравиться он мне стал. Имхо лучше, чем на чистом WinAPI кодить. На NET не всяку прогу начнешь писать, а про его "революционность" можно тут посмотреть: http://www.rsdn.ru/Forum/Info.aspx?name=FAQ.philosophy.itrevolutions