Выдано исключение типа system outofmemoryexception что это

15.05.202215.05.2022 admin 0 Comments

Исправление: Возникает исключение System.OutOfMemoryException или IDE отвечает медленно после построения решения, содержит несколько раз во многих проектах WPF с помощью платформа.NET Framework 3.5 SP1

Симптомы

Создавать сложные решения, содержащего много проектов Windows Presentation Foundation (WPF), основанных на Microsoft платформа.NET Framework 3.5 Пакет обновления 1 (SP1). При каждом построении решения, увеличивается использование памяти процесса devenv.exe. После построения решения несколько раз появиться одно или несколько из следующих проблем:

Исключение типа «System.OutOfMemoryException».

При нажатии любой кнопки в Интегрированной среде разработки IDE медленно реагирует и даже сбоям.

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

Причина

Эта проблема возникает из-за фрагментации памяти между библиотекой классов платформа.NET Framework и средства синтаксического анализа XAML.

Решение

Сведения об исправлении

Существует исправление от корпорации Майкрософт. Однако данное исправление предназначено для устранения только проблемы, описанной в этой статье. Применяйте это исправление только в тех случаях, когда наблюдается проблема, описанная в данной статье. Это исправление может проходить дополнительное тестирование. Таким образом если вы не подвержены серьезно этой проблеме, рекомендуется дождаться следующего пакета обновления, содержащего это исправление.

Если исправление доступно для скачивания, имеется раздел «Пакет исправлений доступен для скачивания» в верхней части этой статьи базы знаний. Если этот раздел не отображается, обратитесь в службу поддержки для получения исправления.

Примечание. Если наблюдаются другие проблемы или необходимо устранить неполадки, вам может понадобиться создать отдельный запрос на обслуживание. Стандартная оплата за поддержку будет взиматься только за дополнительные вопросы и проблемы, которые не соответствуют требованиям конкретного исправления. Чтобы получить полный список телефонов поддержки и обслуживания клиентов корпорации Майкрософт или создать отдельный запрос на обслуживание, посетите следующий веб-сайт корпорации Майкрософт:

http://support.microsoft.com/contactus/?ws=supportПримечание. В форме «Пакет исправлений доступен для скачивания» отображаются языки, для которых доступно исправление. Если нужный язык не отображается, значит исправление для данного языка отсутствует.

Предварительные условия

Платформа.NET Framework 3.5 с пакетом обновления 1 для установки этого исправления необходимо иметь.

Необходимость перезагрузки

Необходимо перезагрузить компьютер после установки исправления, если используется не экземпляр платформа.NET Framework.

Сведения о замене исправлений

Это исправление не заменяет других исправлений.

Сведения о файлах

Английская версия данного исправления содержит атрибуты файла (или более поздние атрибуты файлов), приведенные в следующей таблице. Дата и время для этих файлов указаны в формате общего скоординированного времени (UTC). При просмотре сведений о файле, он преобразуется в локальное время. Чтобы узнать разницу между временем по Гринвичу и местным временем, откройте вкладку Часовой пояс элемента Дата и время в панели управления.

Источник

Out OfMemory Exception Класс

Определение

Некоторые сведения относятся к предварительной версии продукта, в которую до выпуска могут быть внесены существенные изменения. Майкрософт не предоставляет никаких гарантий, явных или подразумеваемых, относительно приведенных здесь сведений.

Исключение, которое выбрасывается при недостаточном объеме памяти для выполнения программы.

Среда CLR не может выделить достаточно непрерывной памяти для успешного выполнения операции. Это исключение может быть создано любым назначением свойства или вызовом метода, требующего выделения памяти. Дополнительные сведения о причине OutOfMemoryException исключения см. в записи блога «недостаточно памяти» не относится к физической памяти.

Этот тип OutOfMemoryException исключения представляет разрушительный сбой. Если решено решить эту ошибку, следует включить catch блок, вызывающий Environment.FailFast метод, чтобы завершить работу приложения и добавить запись в журнал системных событий, как показано в следующем примере.

Некоторые условия, при которых создается исключение, и действия, которые можно предпринять для исключения, включают следующее:

Вызывается StringBuilder.Insert метод.

Предпринимается попытка увеличить длину StringBuilder объекта, превышающего размер, указанный в его StringBuilder.MaxCapacity свойстве. В следующем примере показано исключение, вызываемое OutOfMemoryException вызовом StringBuilder.Insert(Int32, String, Int32) метода, когда в примере предпринимается попытка вставить строку, которая приведет к Length превышению максимального объема свойства объекта.

Для устранения ошибки можно выполнить одно из следующих действий.

Вызовите StringBuilder.StringBuilder(Int32, Int32) конструктор со maxCapacity значением, которое достаточно велико для размещения всех расширений StringBuilder объекта.

Приложение выполняется как 32-разрядный процесс.

32-разрядные процессы могут выделять максимум 2 ГБ памяти виртуального режима пользователя на 32-разрядных системах и 4 ГБ виртуальной памяти в режиме пользователя на 64-разрядных системах. Это может усложнить для среды CLR выделение достаточного непрерывного объема памяти, если требуется большое выделение. В отличие от этого, 64-разрядные процессы могут выделить до 8 ТБ виртуальной памяти. Чтобы устранить это исключение, перекомпилируйте приложение, предназначенное для 64-разрядной платформы. сведения о настройке конкретных платформ в Visual Studio см. в разделе как настроить проекты для целевых платформ.

В приложении происходит утечка неуправляемых ресурсов

Вы пытаетесь создать большой массив в 64-разрядном процессе

Вы работаете с очень большими наборами данных (например, массивами, коллекциями или наборами данных базы данных) в памяти.

Если структуры данных или наборы данных, находящиеся в памяти, становятся настолько большими, что среда CLR не может выделить для них достаточно непрерывной памяти, то OutOfMemoryException результаты исключения.

Чтобы предотвратить OutOfMemoryException исключения, необходимо изменить приложение таким образом, чтобы меньше данных наделено в памяти, или данные разделены на сегменты, требующие меньшего выделения памяти. Пример:

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

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

Если вы используете большие массивы или другие объекты коллекции, размер которых приводит к OutOfMemoryException исключению, следует изменить приложение для работы с данными в подмножествах, а не для совместной работы с ним.

В следующем примере возвращается массив, состоящий из 200 000 000 значений с плавающей запятой, а затем вычисляется их среднее значение. В выходных данных примера показано, что, поскольку в примере сохраняется весь массив в памяти перед вычислением среднего, OutOfMemoryException создается исключение.

В следующем примере исключение устраняется OutOfMemoryException путем обработки входящих данных без сохранения всего набора данных в памяти, сериализации данных в файл при необходимости для дальнейшей обработки (в данном примере эти строки заносятся в комментарий, так как в данном случае они создают файл, размер которого больше 1 ГБ) и возвращают вычисленное среднее и число вариантов в вызывающую подпрограммы.

Вы постоянно объединяете большие строки.

Так как строки являются неизменяемыми, каждая операция сцепления строк создает новую строку. Влияние на небольшие строки или небольшое количество операций объединения незначительно. Но для больших строк или очень большого числа операций сцепления объединение строк может привести к большому количеству выделений памяти и фрагментации памяти, низкой производительности и, возможно, OutOfMemoryException исключений.

При объединении больших строк или выполнении большого числа операций объединения следует использовать StringBuilder класс вместо String класса. Завершив обработку строки, преобразуйте StringBuilder экземпляр в строку, вызвав StringBuilder.ToString метод.

Закрепление большого количества объектов в памяти.

Оцените, нужно ли закреплять каждый объект,

Убедитесь, что каждый объект отменяется закреплением как можно скорее.

Убедитесь, что каждый вызов GCHandle.Alloc(Object, GCHandleType) метода для крепления памяти имеет соответствующий вызов GCHandle.Free метода для открепления этой памяти.

Следующие инструкции промежуточных инструкций (MSIL) Microsoft вызовут OutOfMemoryException исключение:

Конструкторы

Инициализирует новый экземпляр класса OutOfMemoryException.

Инициализирует новый экземпляр класса OutOfMemoryException с сериализованными данными.

Инициализирует новый экземпляр класса OutOfMemoryException с указанным сообщением об ошибке.

Инициализирует новый экземпляр класса OutOfMemoryException указанным сообщением об ошибке и ссылкой на внутреннее исключение, вызвавшее данное исключение.

Свойства

Возвращает коллекцию пар «ключ-значение», предоставляющую дополнительные сведения об исключении.

Получает или задает ссылку на файл справки, связанный с этим исключением.

Возвращает или задает HRESULT — кодированное числовое значение, присвоенное определенному исключению.

Возвращает экземпляр класса Exception, который вызвал текущее исключение.

Возвращает сообщение, описывающее текущее исключение.

Возвращает или задает имя приложения или объекта, вызывавшего ошибку.

Получает строковое представление непосредственных кадров в стеке вызова.

Возвращает метод, создавший текущее исключение.

Методы

Определяет, равен ли указанный объект текущему объекту.

При переопределении в производном классе возвращает исключение Exception, которое является первопричиной одного или нескольких последующих исключений.

Служит хэш-функцией по умолчанию.

При переопределении в производном классе задает объект SerializationInfo со сведениями об исключении.

Возвращает тип среды выполнения текущего экземпляра.

Создает неполную копию текущего объекта Object.

Создает и возвращает строковое представление текущего исключения.

События

Возникает, когда исключение сериализовано для создания объекта состояния исключения, содержащего сериализованные данные об исключении.

Источник

Исключение типа «System.OutOfMemoryException»

Со следующим описанием:
Подробная информация об использовании оперативной
(JIT) отладки вместо данного диалогового
окна содержится в конце этого сообщения.

************** Загруженные сборки **************
mscorlib
Версия сборки: 2.0.0.0
Версия Win32: 2.0.50727.4927 (NetFXspW7.050727-4900)
CodeBase: file:///C:/Windows/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll
—————————————-
RF3
Версия сборки: 0.0.0.0
Версия Win32: 2.0.50727.4927 (NetFXspW7.050727-4900)
CodeBase: file:///C:/Windows/assembly/GAC_32/mscorlib/2.0.0.0__b77a5c561934e089/mscorlib.dll
—————————————-
System
Версия сборки: 2.0.0.0
Версия Win32: 2.0.50727.4927 (NetFXspW7.050727-4900)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
—————————————-
zip
Версия сборки: 0.0.0.0
Версия Win32: 2.0.50727.4927 (NetFXspW7.050727-4900)
CodeBase: file:///C:/Windows/assembly/GAC_32/mscorlib/2.0.0.0__b77a5c561934e089/mscorlib.dll
—————————————-
RF3
Версия сборки: 3.0.0.1
Версия Win32: 2.0.50727.4927 (NetFXspW7.050727-4900)
CodeBase: file:///C:/Windows/assembly/GAC_32/mscorlib/2.0.0.0__b77a5c561934e089/mscorlib.dll
—————————————-
System.Windows.Forms
Версия сборки: 2.0.0.0
Версия Win32: 2.0.50727.4927 (NetFXspW7.050727-4900)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
—————————————-
System.Drawing
Версия сборки: 2.0.0.0
Версия Win32: 2.0.50727.4927 (NetFXspW7.050727-4900)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
—————————————-
Microsoft.VisualBasic
Версия сборки: 8.0.0.0
Версия Win32: 8.0.50727.4927 (NetFXspW7.050727-4900)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/Microsoft.VisualBasic/8.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualBasic.dll
—————————————-
Microsoft.DirectX.Direct3D
Версия сборки: 1.0.2902.0
Версия Win32: 9.05.132.0000
CodeBase: file:///C:/Windows/assembly/GAC/Microsoft.DirectX.Direct3D/1.0.2902.0__31bf3856ad364e35/Microsoft.DirectX.Direct3D.dll
—————————————-
Microsoft.DirectX.DirectInput
Версия сборки: 1.0.2902.0
Версия Win32: 5.04.00.2904
CodeBase: file:///C:/Windows/assembly/GAC/Microsoft.DirectX.DirectInput/1.0.2902.0__31bf3856ad364e35/Microsoft.DirectX.DirectInput.dll
—————————————-
Microsoft.VisualC
Версия сборки: 8.0.0.0
Версия Win32: 8.00.50727.4927
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/Microsoft.VisualC/8.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualC.dll
—————————————-
Microsoft.DirectX
Версия сборки: 1.0.2902.0
Версия Win32: 5.04.00.2904
CodeBase: file:///C:/Windows/assembly/GAC/Microsoft.DirectX/1.0.2902.0__31bf3856ad364e35/Microsoft.DirectX.dll
—————————————-
Microsoft.VisualBasic.Compatibility
Версия сборки: 8.0.0.0
Версия Win32: 8.0.50727.4927
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/Microsoft.VisualBasic.Compatibility/8.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualBasic.Compatibility.dll
—————————————-
System.Windows.Forms.resources
Версия сборки: 2.0.0.0
Версия Win32: 2.0.50727.4927 (NetFXspW7.050727-4900)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Windows.Forms.resources/2.0.0.0_ru_b77a5c561934e089/System.Windows.Forms.resources.dll
—————————————-
Microsoft.DirectX.DirectSound
Версия сборки: 1.0.2902.0
Версия Win32: 5.04.00.2904
CodeBase: file:///C:/Windows/assembly/GAC/Microsoft.DirectX.DirectSound/1.0.2902.0__31bf3856ad364e35/Microsoft.DirectX.DirectSound.dll
—————————————-
mscorlib.resources
Версия сборки: 2.0.0.0
Версия Win32: 2.0.50727.4927 (NetFXspW7.050727-4900)
CodeBase: file:///C:/Windows/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll
—————————————-
System.Xml
Версия сборки: 2.0.0.0
Версия Win32: 2.0.50727.4927 (NetFXspW7.050727-4900)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll
—————————————-
Microsoft.DirectX.Direct3DX
Версия сборки: 1.0.2911.0
Версия Win32: 9.12.589.0000
CodeBase: file:///C:/Windows/assembly/GAC/Microsoft.DirectX.Direct3DX/1.0.2911.0__31bf3856ad364e35/Microsoft.DirectX.Direct3DX.dll
—————————————-
Accessibility
Версия сборки: 2.0.0.0
Версия Win32: 2.0.50727.4927 (NetFXspW7.050727-4900)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/Accessibility/2.0.0.0__b03f5f7f11d50a3a/Accessibility.dll
—————————————-
Microsoft.VisualBasic.resources
Версия сборки: 8.0.0.0
Версия Win32: 8.0.50727.4927 (NetFXspW7.050727-4900)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/Microsoft.VisualBasic.resources/8.0.0.0_ru_b03f5f7f11d50a3a/Microsoft.VisualBasic.resources.dll
—————————————-
Microsoft.DirectX.AudioVideoPlayback
Версия сборки: 1.0.2902.0
Версия Win32: 5.04.00.2904
CodeBase: file:///C:/Windows/assembly/GAC/Microsoft.DirectX.AudioVideoPlayback/1.0.2902.0__31bf3856ad364e35/Microsoft.DirectX.AudioVideoPlayback.dll
—————————————-

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

Источник

Блог Александра Кондуфорова

об информационных технологиях, программировании, путешествиях и фотографии

Thursday, August 28, 2008

OutOfMemoryException и как его побороть

Думаю, многие разработчики в своей практике сталкивались с такой неприятной исключительной ситуацией, как OutOfMemoryException. Чем она неприятна? Тем, что она свидетельствует об одной из двух вещей: либо ваше приложение скушало всю доступную память и сделало это ожидаемо, потому что вы его так запрограммировали, либо оно сделало это вследствие утечки памяти (memory leak). И первый, и второй случай чреваты серьезными проблемами. В первом случае нам нужно рефакторить код и, возможно, даже архитектуру с целью избежания этой ситуации в дальнейшем, и не факт, что при этом не придется придумывать какие-нибудь обходные методы. Во втором случае мы сталкиваемся с тем, что мы, скорее всего, понятия не имеем, где происходит утечка и как с этим бороться, то есть у нас налицо предстоящий достаточно сложный дебаг. И самое неприятное во всей этой ситуации то, что мы не знаем, с каким же все-таки вариантом мы имеет дело. А если не знаем, значит, самое время взять ~~скальпель~~ стетоскоп и прослушать пациента.

Итак, попробуем разобраться, что же происходит внутри нашего приложения

Первый шаг очень простой: необходимо собрать как можно больше информации. Для начала общаемся с QA, которые нашли баг и пытаемся выяснить условия, при которых воспроизводится баг. OutOfMemoryException – исключение подлое, в большинстве случаев оно не воспроизводится в лоб, а просто вылетает в какой-то момент жизни приложения, когда память переполнится. Полученная информация нам поможет и для воспроизведения бага, и для собственного понимания того, что творится внутри процесса. В частности, у нас вот проблема в основном проявлялась при большом количестве пользователей, что неудивительно, так как сессии довольно большие, но все равно странно, так как непонятно, чем же занимается в таком случае сборщик мусора? Ну, о причинах этого потом – в примере.

Используем встроенные средства мониторинга ОС

На втором шаге мы пробуем минимальными усилиями разобраться с тем, что у нас происходит с памятью в процессе и сколько памяти у нас выделяется под сессию. Сделать это очень просто при помощи стандартных счетчиков производительности (performance counters) Windows. Нам пригодятся следующие как минимум счетчики, но вы можете воспользоваться и расширенным списком (помните, что включать их нужно для вашего процесса aspnet_wp/w3wp):

Выглядеть это будет примерно так:

Собственно, здесь мы хотим посмотреть размеры куч всех трех поколений и LOH, а также общую занятую память и committed/reserved bytes. Reserved bytes показывает, сколько наше приложение зарезервировало себе памяти, committed – сколько оно реально из этого количества уже использует. Отличное описание этих и других полезных счетчиков и их назначение можно найти здесь. Итак, запускаем счетчики и Windows Task Manager (с ним будем отслеживать Mem usage и VM usage для процесса aspnet_wp/w3wp), заполняем себе табличку в Excel – и поехали.

Настоятельно рекомендую перед работой с Task Manager прочитать пост Tess. В частности, там можно прочитать вот такую интересную вещь:

«If you want to see this in action, you can create a winforms application and allocate a bunch of objects and see the working set go up, and then if you minimize the app, the working set drops. This doesn’t by any means mean that you have just released all this memory. It just means that you are looking at a counter that is totally irrelevant for determining how much stuff you store in memory 🙂 Yet. this is the counter that people most often look at to determine memory usage.

I know that by now you are probably thinking «yeah right», you haven’t even heard of this counter before, why would I say that this is the counter most people look at. The answer is, because most people use task manager to look at memory usage of a process, and specifically look at the Memory Usage column. Surprise surprise:) what this actually shows you is the working set of the process.

If you want to see private bytes which is a far more interesting counter, you should look at the column in task manager that is labeled Virtual Memory Size (yeah, that’s really intuitive:)), or better yet, look in performance monitor at process\private bytes and process\virtual bytes, there is no reason not to if your intent is to investigate high memory usage or a memory leak. «

Так что будьте осторожны 😉

Логинимся в приложение одним пользователем, делаем замеры, логинимся следующим, делаем замеры. По пути можно попробовать просмотреть разную функциональность системы, чтобы увидеть, где именно мы получаем большое увеличение памяти. По размерам куч видим, как постепенно увеличивается количество памяти, и что у нас чистится GC, а что – нет. По Mem usage и VM usage определяем общее количество используемой памяти и пытаемся путем несложных арифметических операций определить, сколько же все-таки у нас занимает один пользователь в сессии. В нашем случае уже на 10 пользователях приходит понимание, что общее количество памяти растет непомерно и освобождаться почему-то не хочет. Ну, это логично – созданные сессии еще активны и сборщик мусора их собрать не может. Ставим опыт: отпускаем приложение на уровне 700 Мб и уходим на полчаса пить чай. Через полчаса заходим на сайт новым пользователем и делаем очередной замер. Нет, почти ничего не изменилось, используемая память продолжает увеличиваться, хотя должна была существенно уменьшится. Размер одной сессии в среднем – 30-40 Мб, что слишком много. Итак, либо у нас по какой-то причине не очищаются сессии, либо утечка памяти в другом месте. Информации по-прежнему мало. Пора браться за более серьезные инструменты анализа.

Знакомимся с тяжелой артиллерией

В роли тяжелой артиллерии может выступать практически любой performance tool, который умеет нормально мониторить память. Тулов много, но толковую информацию предоставляют единицы. Лично я все не смотрел, но вот мой любимый dotTrace, который не раз помогал мне находить performance-проблемы в коде, здесь полностью облажался. Ничего толкового из него я добиться не смог, может, просто руки кривые 🙂 Поэтому, если у вас нет особых вариантов, то советую сразу же взяться за WinDbg. WinDbg – это универсальный дебаггер, которая позволяет отлаживать любые win-приложения. А самое классное в нем то, что он позволяет не только подключаться к приложению и отлаживать в онлайн-режиме, но умеет еще и анализировать т.н. user dump’ы, то есть снимки внутреннего состояния приложения. Сделать эти снимки можно при помощи тулы User Mode Process Dumper, а WinDbg можно найти в пакете Debugging Tools for Windows. Итак, выполним подготовительные действия по шагам:

После всех указанных действий вы увидите картинку наподобие следующей:

Анализируем дамп процесса

Теперь подключаем sos.dll к WinDbg при помощи команды:

.load C:\ \Microsoft.NET\ Framework\v2.0.50727\sos.dll

Как видите, команд здесь довольно много. Я не буду останавливаться на всех них. Подробное описание процесса инсталляции и команд можно найти в секции Debugging School блога Johan Straarup:

Теперь, когда мы знаем минимально необходимый набор команд, я покажу приблизительный алгоритм поиска источника проблемы.

Начнем мы с анализа памяти. Проверим, что у нас вообще творится в куче:

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

Здесь мы тоже видим довольно много интересного. Во-первых, для будущих тестов нам нужны MT (что-то типа идентификатора типа объекта) объектов System.Web.Caching.Cache и System.Web.SessionState.InProcSessionState, которые соответствуют глобальному кешу приложения и его сессиям, которые наравне с другими объектами кеша хранятся в нем. Еще мы видим, что у нас очень много объектов хранится в массивах строк, но толку нам пока от этого немного. Вот если бы там были какие-то более специфические объекты, например, DataTable, мы могли бы туда сходить и посмотреть более серьезно. А так глянем сначала, сколько у нас занимается кеш в целом и сессии в частности. Для этого сначала нужно найти адреса этих объектов:

Итак, кеш весит 336 Мб, а сессий у нас 6 штук. Берем первую попавшуюся и смотрим ее размер:

Смотрим следующую – размер тот же, причем до байта. Еще одну – аналогично. Явно что-то не так в датском королевстве. Суммарный размер 6 сессий будет явно превышать размер объекта кеша, чего не может быть в принципе, так как объект Cache содержит в себе сессии. Однако, здесь есть особенность, которая может объяснить эту нестыковку – дело в том, что sos при подсчете размера объекта включает в него и размер всех объектов, на которые данный объект ссылается. Значит, у нас где-то сессии друг на друга ссылаются. Вот только где и как? Кроме того, мы можем сделать еще один важный вывод: чистая информация, которую мы вносили в кеш руками, занимает очень мало памяти, что очень хорошо. Если бы разница была больше, то нужно было бы идти анализировать еще и закешированные данные.

Посмотрим, что у нас хранится в сессии:

Как мы видим, в сессии хранится лишь некий экземпляр класса Custom.Namespace.SomeClass, который содержит перечисленный набор полей. В принципе, это известно давно тем, кто приложение программировал 🙂 Колонка Value показывает значения ссылок, нолики, как несложно догадаться – это null. Теперь посмотрим размеры объекта model:

Итак, главный объект SomeAnotherClass весит около 335 Мб, в то время как вложенный в него OneMoreAnotherClass – всего 63 Мб. Возможно, другие объекты содержат остальные данные? Проверяем – нет, не так. Хотя в нашем случае даже проверять не нужно было – мы и так знаем свой код 🙂 Проверяем другие сессии аналогичным образом – там та же картина, что вполне ожидаемо. Итак, к чему мы пришли? Наш Custom.Namespace.SomeClass и вложенный в него Custom.Namespace.SomeAnotherClass содержится в каждой сессии, а то, что objsize показывает для него размер всех сессий, указывает, что на этом уровне у нас возможны проблемы.

А теперь посмотрим, кто на кого ссылается:

А вот и корень зла. Если посмотреть этот trace, то можно увидеть, что поначалу у нас все замечательно, кеш, сессия, а потом начинаются странности. Откуда-то появляются ссылки через делегаты, а класс SomeAnotherClass вообще фигурирует дважды, причем по разным адресам. Однако подсказка тоже есть – Custom.ApproveActionWorkflow.WorkflowManager+WorkflowNotificationsSentDelegate. Немного подумав, вспоминаем, что у нас есть замечательный синглтон-класс WorkflowManager, который предназначен для взаимодействия между пользовательскими потоками и потоком WorkflowRuntime, и оповещает все сессии при помощи генерации события о том, что им пора бы обновить некоторые специфические данные из базы. И он, конечно же, подписывает все создаваемые сессии на свое событие. А потом держит эту ссылку бесконечно, таким образом не давая сборщику мусора собрать сессии. Ну все, разобрались. Теперь дело за малым: зарефакторить код, чтобы сессии сами опрашивали класс об изменениях и избавиться от OutOfMemoryException 🙂 Дело сделано.

Выводы из данной ситуации очень простые:

1) Делегаты, как оказывается – звери совсем не безобидные, за ними тоже нужен глаз да глаз
2) Старайтесь внимательно реализовывать межсессионное взаимодействие, чтобы не допускать не только ссылок на объекты, но и на функции
3) Не забывайте про особенности работы Task Manager и то, что он реально показывает. Не нужно на него сильно полагаться
4) Если же у вас все-таки вылетает OutOfMemoryException, не отчаивайтесь. Вооружайтесь дампом и WinDbg – и вперед. Люди и не такие баги отлаживают 🙂
5) WinDbg подойдет и для отладки других сложных ситуаций. Вот, например, рассказ Юры Скалецкого и некоего JKealey. Там есть что почитать.

Ну, и напоследок я настоятельно вам советую следующие статьи из блога Tess и Johan’а по поводу отладки утечек памяти:

Да и вообще, эти блоге стоит добавить в ваш персональный RSS feeder. Можно вместе с блогом Марка Руссиновича (ага, это тот, который написал кучу полезных системных тулов, известных под названием Sysinternals). Пригодятся.

Источник

Строительный портал zabor-61.ru

Выдано исключение типа system outofmemoryexception что это

Симптомы

Причина