Охота на EOutOfResources

Если это утечки дескрипторов GDI, вы можете взглянуть на Журнал MSDN, январь 2003 г., в котором используется инструмент GDILeaks. Другие инструменты: GDIObj или GDIView. См. Также здесь .

Другой источник EOutOfResources может заключаться в том, что Desktop Heap заполнен. У меня была эта проблема на загруженных терминальных серверах с большими экранами.

Если у вас много дескрипторов файлов, вы можете проверить Process Explorer и взглянуть на открытые дескрипторы файлов вашего процесса и увидеть любые необычные. Или используйте WinDbg с ! htrace.

Существует небольшая вероятность того, что ошибка вводит в заблуждение. VCL наивно сообщает EOutOfResources, если не может получить DC для окна (см. TWinControl.GetDeviceContext в Controls.pas).

Я говорю «наивно», потому что есть и другие причины, по которым GetDC () может возвращать нулевой дескриптор, а VCL должен сообщать об ошибке ОС, а не предполагать состояние нехватки ресурсов ( для того, чтобы это было надежно возможно, требуется проверка версии Windows, но VCL может и должна это взять).

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

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

Я сталкивался с этой проблемой раньше. Из того, что я смог сказать, Delphi может выдать EOutOfResources в любое время, когда Windows API возвращает ERROR_NOT_ENOUGH_MEMORY, и (как обсуждают другие ответы здесь) Windows может возвращать ERROR_NOT_ENOUGH_MEMORY для различных условий.

В моем случае EOutOfResources был вызван TBitmap - в частности, вызов TBitmap для CreateCompatibleBitmap, который он использует с PixelFormat по умолчанию для pfDevice. Очевидно, Windows может применять довольно строгие общесистемные ограничения на объем памяти, доступной для зависящих от устройства растровых изображений (см., Например, это обсуждение), даже если в остальном ваша система имеет много памяти и много ресурсов GDI. (Эти общесистемные ограничения, по-видимому, вызваны тем, что Windows может выделять зависящие от устройства растровые изображения в памяти видеокарты.)

Решение состоит в том, чтобы вместо этого просто использовать независимые от устройства растровые изображения (DIB) (хотя они могут не обеспечивать такую ​​высокую производительность). Для этого в Delphi установите для TBitmap.PixelFormat любое значение, кроме pfDevice. В этой статье базы знаний описывается, как выбрать оптимальный формат DIB для устройства, хотя Обычно я просто использую pf32Bit вместо того, чтобы пытаться определить оптимальный формат для каждого из мониторов, на которых отображается приложение.

В большинстве случаев я видел EOutOfResources, это была какая-то утечка дескриптора.

Вы пробовали что-то вроде MadExcept?

- Джерун

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

Я снимаю здесь в темноте, но может быть, вы используете Windows API для (GetTempFileName) создания временного файла, и вы выдуваете некоторые индексы файловой системы или забываете закрыть дескриптор файла?

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

Также попробуйте проверить количество дескрипторов для приложения с помощью Process Explorer от SysInternals. Утечки в ручках могут быть очень опасными, и они медленно нарастают с течением времени.

В настоящее время у меня возникла эта проблема в программном обеспечении, которое явно не пропускает никаких дескрипторов в моем собственном коде, поэтому, если есть утечки, они могут происходить в исходном коде компонента или самом исходном коде VCL.

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

На данный момент лучшая стратегия, которую я нашел для их поиска, - это использовать либо трассировку стека JCL JCLDEBUG, либо функции сохранения отчета об исключениях в MadExcept для генерации контекстной информации, чтобы выяснить, что на самом деле дает сбой.

Во-вторых, AQTime содержит множество инструментов, которые могут вам помочь, в том числе профилировщик ресурсов, который может поддерживать связи между тем, где находится код, создавший ресурсы, и тем, как он был вызван, а также подсчет общего количества дескрипторов. Он может захватывать результаты MID RUN и поэтому не ограничивается обнаружением неиспользованных ресурсов после выхода. Итак, запустите AQTime, сделайте захват результатов в середине выполнения, подождите несколько часов и снова захватите, и у вас должно быть два момента времени для сравнения счетчиков дескрипторов. На всякий случай это очевидная вещь. Но, как мудро указывает Deltics, этот класс исключения возникает в тех случаях, когда этого, вероятно, не должно было быть.

Я потратил весь сегодня на поиски этого вопроса. Я нашел множество полезных ресурсов, указывающих мне в сторону GDI, с тем фактом, что я использую GDI + для создания высокоскоростной анимации непосредственно в основной форме с помощью timer / invalidate / onpaint (анимация выполняется в отдельном потоке). У меня также есть панель в этой форме с некоторыми динамически создаваемыми элементами управления, чтобы пользователь мог вносить изменения в анимацию.

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

Я внимательно следил за своим кодом и удостоверился, что у меня нет дескрипторов, связанных с GDI. На самом деле, согласно диспетчеру задач, все мое приложение имеет менее 300 дескрипторов. Тем не менее, эта ошибка будет появляться случайным образом. И это всегда будет соответствовать простейшему действию, связанному с пользовательским интерфейсом, например, просто наведению указателя мыши на стандартный элемент управления VCL.

Решение

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

То есть, по крайней мере, с 1 часом интенсивного тестирования.

[Скрещенные пальцы]