В поисках пузыря памяти - PullRequest
3 голосов
/ 04 февраля 2009

Это либо смехотворно просто, либо слишком сложно. , , .

В нашем приложении есть форма, которая загружает некоторые данные из базы данных и отображает их в сетке (проще говоря). Когда данные обновляются, общее использование памяти увеличивается приблизительно на 50 КБ (в зависимости от того, сколько данных отображается, без сомнения). Звучит как утечка памяти, но когда мы закрываем приложение, FastMM имеет значение ReportMemoryLeakOnShutDown: = True и не сообщает о каких-либо ненормальных утечках памяти.

Похоже, у нас есть пузырь памяти или сумка. То, что накапливает больше памяти при каждом запуске. Как TList, который продолжает добавлять новые элементы , но старые никогда не удаляются. Затем в процессе выключения все предметы уничтожаются. Строки, отображаемые в сетке, не увеличиваются, но за кулисами есть множество списков объектов, которые делают эту работу, поэтому она может быть где угодно.

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

Заранее спасибо!

Обновление: Каждое обновление приводит к использованию дополнительных 10-50 КБ памяти. Пользователи сообщают, что в конечном итоге приложение перестает отвечать на запросы. Это конечно действует как утечка памяти, но FastMM (диспетчер памяти) не видит ничего утечки. Я попробую некоторые другие инструменты памяти. , ,

Ответы [ 7 ]

6 голосов
/ 04 февраля 2009

Инструменты типа AQTime могут сообщать о разнице в использовании памяти / объекта между снимками. Это может помочь вам узнать, что продолжает расти.

6 голосов
/ 04 февраля 2009

Просто проведите F8 через критическую часть и посмотрите на график использования процесса (для этого отлично работает Process Explorer от Марка Руссиновича). Когда вы найдете метод виновника, повторите процесс, но погрузитесь в этот метод.

3 голосов
/ 04 февраля 2009

Похоже, что некоторая память выделяется через пользовательские вызовы AllocMem (), минуя FastMM.

Это может быть Мидас. У Андреаса есть решение для этого

Или какой-то другой вызов InitXXX WinAPI, который выделяет что-то без освобождения. Или какой-то другой сторонний или windows dll, используемый проектом.

0 голосов
/ 05 февраля 2009

Как упоминал Ларс Труидженс, AQTime предоставляет график потребления оперативной памяти, поэтому во время выполнения вы можете видеть, какие объекты используют больше памяти при каждом обновлении данных.

0 голосов
/ 04 февраля 2009

Однажды у меня возникла такая же проблема. Приложение, конечно, протекало, но я не получил отчета о завершении работы. Причиной этого было то, что я включил sharemem в раздел пользователей проекта.

Пробовали ли вы полную FastMM-версию? Я обнаружил, что настройка его параметров дает мне более подробную информацию об использовании памяти.

0 голосов
/ 04 февраля 2009

Я не эксперт FastMM, но я полагаю, что после того, как менеджер памяти получит память, после того, как вы освободите объекты / компоненты, он останется для будущего использования с некоторыми нулями или флагом, я не знаю, избегая необходимости спрашивать ОС для дополнительной памяти в любое время, например, кеш.

Как насчет того, чтобы создать одну и ту же форму / открыть одни и те же данные, N раз подряд? Будет увеличиваться на 50К каждый раз?

0 голосов
/ 04 февраля 2009

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

Есть много инструментов, которые предоставляют вам информацию об утечках памяти, вы пробовали другой?

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...