Вопрос:

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

Я знаю, что memproof может это сделать, но он настолько тормозит, что приложение не будет работать даже минуту. Большинство лайков менеджера задач могут показывать номер, но не тип.

Это не проблема, что сама проверка является катастрофической (останавливает процесс приложения), так как я могу проверить с помощью taskmgr, если я подхожу близко (или, по крайней мере, я надеюсь)

Любое другое понимание поиска утечек ресурсов (а не памяти) также приветствуется.

Фон:

У меня есть приложение Delphi 7/2006/2009 (компилируется со всеми тремя), и через несколько недель оно начинает вести себя забавно. Однако только в одном из мест, где он работает, в нескольких других системах он работает, пока не отключится питание.

Я попытался вставить некоторый отладочный код, чтобы сузить проблему. и обнаружил, что исключением является EOutofResources при сохранении файла. (сохранение файла может происходить тысячи раз в день).

Я пытался выяснить утечки памяти (с fastmm), но так как поток данных довольно высок (60 МБ / с от гигабитной промышленной камеры), я могу исключить только «ползучие» утечки памяти с fastmm, а не быстрые вспышки утечек памяти, которые истощают память о времени, когда это происходит. Если что-то идет не так, приложение заполняет память менее чем за полминуты.,

Основными подозреваемыми являются файловые дескрипторы, которые каким-то образом остаются при некоторых ошибках, и TMetafiles (которые передаются в эти файлы). Незначительными подозреваемыми являются VST, popupmenu и tframes

Обновления:

Другой возможный совет: в течение двух лет он работал нормально с D7, и теперь проблемы с Turbo Explorer (который я использую для стабильных проектов, не преобразованных в D2009).

Пол-Ян: Поскольку это происходит только раз в неделю (а это может происходить ночью), сбор информации происходит медленно. Именно поэтому я задаю этот вопрос, нужно объединить вещи для того времени, когда я буду там в четверг. Короче говоря: нет, я не знаю, уверен на 100%. Я собираюсь принести всю коллекцию Systemtools, чтобы посмотреть, смогу ли я что-нибудь найти (потому что тогда она будет работать несколько дней). Также есть вероятность, что я вижу открытые файлы. (возможно, следует попытаться найти mingw lsof и запланировать это)

Но приложение видит очень мало действий с графическим интерфейсом (это приложение для проверки машинного зрения), за исключением обновления экрана +/- 15 / с, которое представляет собой tbitmap stretchdraw + tmetafile, но я получаю эту ошибку при сохранении на диск (TFileStream), вероятно, дескрипторыдействительно истощены. Однако в том же потоке TMetafile также сохраняется в потоковом режиме, чего у более поздних приложений больше нет, и они могут работать в течение нескольких месяцев.

------------------- ОБНОВИТЬ

Я искал и искал и искал, и мне удалось воспроизвести проблемы в пробирке два или три раза. Проблемы возникали, когда размер memusage составлял +/- 256 МБ (системы имеют 2 ГБ), пользовательские объекты 200, объекты gdi 500, ни один файл не был открыт больше, чем ожидалось).

Это не совсем исключительное. Я замечаю, что я пропускаю небольшое количество дескрипторов, возможно, из-за перерисовки кадров (что-то в VCL, похоже, пропускает HPalette), но я подозреваю, что основная причина - это другая проблема. Я повторно использую TMetafile, и .clear его между ними. Я думаю, что очистка метафайла на самом деле (всегда?) Не изменяет размер ресурса, в конечном итоге каждый метафайл во всем пуле tmetafile в максимальном размере, и с 20-40+ tmetafiles (которые могут быть несколько 100ks каждый) это попадет на рабочий стол предел кучи.

Это теория, но я попытаюсь проверить это, установив ограничение рабочего стола на 10 МБ для клиентов, но пройдет несколько недель, прежде чем я получу подтверждение, если это что-то изменит. Эта теория также подтверждает, почему эта машина особенная (возможно, эта машина в среднем имеет несколько большие метафайлы). Иногда может помочь освобождение и воссоздание tmetafile в пуле.

К счастью, все эти проблемы (как tmetafile, так и reparenting) уже разработаны в новых поколениях приложений.

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

Другое дело, что аудит выявил использование GDI-типов в потоке (хотя сохранял только tmetafiles (которые не использовались или не подключались иным образом) в потоки.

------------- Обновление 2.

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

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

Подводя итог, я могу только заявить, что три основных модификации шли от старого к новому фреймворку:

Я больше не меняю экраны, перерисовывая кадры. Теперь я работаю с формами, которые я скрываю и показываю. Я изменил это, так как у меня также были очень редкие сбои или исключения (которые могли быть удалены) из-за этого. Аварии происходили во время работы с графическим интерфейсом, а не спонтанно, как основная проблемаПроцедура, в которой произошел сбой, касалась TMetafile. TMetafile был разработан и заменен более простым форматом собственного производства. (в основном массивы с вершинами Opengl)Рисование больше не происходило с tbitmap с растянутым наложением tmetafile, но с использованием OpenGL.

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

Обновлено ноябрь 2012 после некоторого обсуждения в частной почте: в ретроспективе следующим шагом было бы добавление счетчика к объектам метафайлов и просто повторное использование их каждые x * 1000 или около того, и посмотреть, изменит ли это что-нибудь. Если у вас есть похожие проблемы, попробуйте посмотреть, сможете ли вы регулярно уничтожать и повторно инициализировать долгоживущие ресурсы, которые динамически распределяются.