Внешний компонент создал исключение как исправить

Whenever a user reports an error such as

System.Runtime.InteropServices.SEHException — External component has thrown an exception?

is there anything that I as a programmer can do to determine the cause?

Scenario : One user (using a program my company wrote) has reported this error.
This may or may not have been a one off error. They mentioned that in the last month, the computer has twice ‘stopped working’. I have learnt from experience, not to take this description too literally, as it usually means that someone relating to the computer is not working as expected. They were unable to give me more details and I could not find any logged errors. Hence it may or may not have been this error.

From the stack-trace, the actual error was when constructing a class which does not directly call any interop code, but perhaps complicated by the fact that the object may be part of a list that is databound to a DevExpress Grid.

The error was ‘caught’ by an unhandled exception routine which normally will close down the program, but has an option to ignore and continue. If they opted to ignore the error, then the program continued working but the error re-occurred when this routine was next run. However it did not occur again after closing and restarting our application.

The computer in question did not seem to be stressed out. It is running Vista Business, has 2GB of memory and according to Task Manager was only using about half of that with our application just about 200Mb.

There is one other piece of information that may or may not be relevant. Another section of the same program uses a third party component which is effectively a dotnet wrapper around a native dll and this component does have a known issue where very occasionally, you get a

Attempted to read or write protected memory. This is often an indication that other memory is corrupt

The component makers say that this has been fixed in the latest version of their component which we are using in-house, but this has not been given to the customer yet.

Given that the consequences of the error are low (no work is lost and restarting the program and getting back to where they were only takes a minute at most) and given that the customer will shortly be getting a new version (with the updated third-party component), I can obviously cross my fingers and hope the error won’t occur again.

But is there anything more I can do?

Whenever a user reports an error such as

System.Runtime.InteropServices.SEHException — External component has thrown an exception?

is there anything that I as a programmer can do to determine the cause?

Scenario : One user (using a program my company wrote) has reported this error.
This may or may not have been a one off error. They mentioned that in the last month, the computer has twice ‘stopped working’. I have learnt from experience, not to take this description too literally, as it usually means that someone relating to the computer is not working as expected. They were unable to give me more details and I could not find any logged errors. Hence it may or may not have been this error.

From the stack-trace, the actual error was when constructing a class which does not directly call any interop code, but perhaps complicated by the fact that the object may be part of a list that is databound to a DevExpress Grid.

The error was ‘caught’ by an unhandled exception routine which normally will close down the program, but has an option to ignore and continue. If they opted to ignore the error, then the program continued working but the error re-occurred when this routine was next run. However it did not occur again after closing and restarting our application.

The computer in question did not seem to be stressed out. It is running Vista Business, has 2GB of memory and according to Task Manager was only using about half of that with our application just about 200Mb.

There is one other piece of information that may or may not be relevant. Another section of the same program uses a third party component which is effectively a dotnet wrapper around a native dll and this component does have a known issue where very occasionally, you get a

Attempted to read or write protected memory. This is often an indication that other memory is corrupt

The component makers say that this has been fixed in the latest version of their component which we are using in-house, but this has not been given to the customer yet.

Given that the consequences of the error are low (no work is lost and restarting the program and getting back to where they were only takes a minute at most) and given that the customer will shortly be getting a new version (with the updated third-party component), I can obviously cross my fingers and hope the error won’t occur again.

But is there anything more I can do?

Здравствуйте.Всегда при попытке запуска игры вылетает табличка «Платформа
microsoft.NET Framework— необрабатываемое исключение в
приложении. При нажатии кнопки «Продолжить» приложение проигнорирует ошибку и попытаетеся продолжить работу. При нажатии кнопки «выход» приложение немедленно завершит работу.

Подробная информация об использовании оперативной

(JIT) отладки вместо данного диалогового

окна содержится в конце этого сообщения.

************** Текст исключения **************

System.Runtime.InteropServices.SEHException: Внешний компонент создал исключение.

   в BmLauncherLib.PhysXSDK.{ctor}(PhysXSDK* )

   в BmLauncherUtils.PhysXSDK..ctor()

   в BmLauncher.Settings.DetermineDefaultPhysXLevel()

   в BmLauncher.Settings.StaticInitialise(IniFile iniFile, IniFile iniEng, IniFile iniInst, SystemInfo sysInfo, String localePath, String localeConfigFile)

   в BmLauncher.Form1.Initialise()

   в BmLauncher.Form1.OnLoad(Object sender, EventArgs e)

   в System.Windows.Forms.Form.OnLoad(EventArgs e)

   в System.Windows.Forms.Form.OnCreateControl()

   в System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)

   в System.Windows.Forms.Control.CreateControl()

   в System.Windows.Forms.Control.WmShowWindow(Message& m)

   в System.Windows.Forms.Control.WndProc(Message& m)

   в System.Windows.Forms.ScrollableControl.WndProc(Message& m)

   в System.Windows.Forms.ContainerControl.WndProc(Message& m)

   в System.Windows.Forms.Form.WmShowWindow(Message& m)

   в System.Windows.Forms.Form.WndProc(Message& m)

   в System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)

   в System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)

   в System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

************** Загруженные сборки **************

mscorlib

    Версия сборки: 2.0.0.0

    Версия Win32: 2.0.50727.5485 (Win7SP1GDR.050727-5400)

    CodeBase: file:///C:/Windows/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll

—————————————-

BmLauncher

    Версия сборки: 1.0.1.0

    Версия Win32: 1.0.1.0

    CodeBase: file:///C:/Program%20Files%20(x86)/Origin%20Games/Batman%20Arkham%20Asylum%20Game%20of%20the%20Year%20Edition/Binaries/BmLauncher.exe

—————————————-

System.Windows.Forms

    Версия
сборки: 2.0.0.0

    Версия Win32: 2.0.50727.5491 (Win7SP1GDR.050727-5400)

    CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll

—————————————-

System

    Версия
сборки: 2.0.0.0

    Версия Win32: 2.0.50727.5485 (Win7SP1GDR.050727-5400)

    CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll

—————————————-

System.Drawing

    Версия
сборки: 2.0.0.0

    Версия Win32: 2.0.50727.5491 (Win7SP1GDR.050727-5400)

    CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll

—————————————-

System.Management

    Версия
сборки: 2.0.0.0

    Версия Win32: 2.0.50727.5483 (Win7SP1GDR.050727-5400)

    CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Management/2.0.0.0__b03f5f7f11d50a3a/System.Management.dll

—————————————-

BmLauncherUtils

    Версия сборки: 1.0.0.0

    Версия Win32: 1.0.1.0

    CodeBase: file:///C:/Program%20Files%20(x86)/Origin%20Games/Batman%20Arkham%20Asylum%20Game%20of%20the%20Year%20Edition/Binaries/BmLauncherUtils.DLL

—————————————-

msvcm80

    Версия сборки: 8.0.50727.6195

    Версия Win32: 8.00.50727.6195

    CodeBase: file:///C:/Windows/WinSxS/x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.6195_none_d09154e044272b9a/msvcm80.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

—————————————-

System.Xml

    Версия
сборки: 2.0.0.0

    Версия Win32: 2.0.50727.5485 (Win7SP1GDR.050727-5400)

    CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll

—————————————-

mscorlib.resources

    Версия
сборки: 2.0.0.0

    Версия Win32: 2.0.50727.5485 (Win7SP1GDR.050727-5400)

    CodeBase: file:///C:/Windows/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll

—————————————-

System.Windows.Forms.resources

    Версия
сборки: 2.0.0.0

    Версия Win32: 2.0.50727.5420 (Win7SP1.050727-5400)

    CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Windows.Forms.resources/2.0.0.0_ru_b77a5c561934e089/System.Windows.Forms.resources.dll

—————————————-

************** Оперативная отладка (JIT) **************

Для подключения оперативной (JIT) отладки файл .config данного

приложения или компьютера (machine.config) должен иметь

значение jitDebugging, установленное в секции system.windows.forms.

Приложение также должно быть скомпилировано с включенной

отладкой.

Например:

<configuration>

    <system.windows.forms jitDebugging=»true» />

</configuration>

При включенной отладке JIT любое необрабатываемое исключение

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

вместо того чтобы обрабатываться данным диалоговым окном.

Как следует диагностировать ошибку SEHException — Внешний компонент вызвал исключение

Каждый раз, когда пользователь сообщает об ошибке, например

System.Runtime.InteropServices.SEHException — Внешний компонент вызвал исключение?

Могу ли я, как программист, что-нибудь сделать, чтобы определить причину?

Сценарий: об этой ошибке сообщил один пользователь (использующий программу, написанную моей компанией). Это могло быть или не быть разовой ошибкой. Они упомянули, что за последний месяц компьютер дважды «переставал работать». На собственном опыте я научился не понимать это описание слишком буквально, поскольку обычно это означает, что кто-то, имеющий отношение к компьютеру, работает не так, как ожидалось. Они не смогли предоставить мне более подробную информацию, и я не смог найти никаких зарегистрированных ошибок. Следовательно, это могла быть или не быть эта ошибка.

Из трассировки стека фактическая ошибка возникла при создании класса, который напрямую не вызывает какой-либо код взаимодействия, но, возможно, осложнен тем, что объект может быть частью списка, привязанного к DevExpress Grid.

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

Рассматриваемый компьютер, похоже, не был перегружен. Он работает под управлением Vista Business, имеет 2 ГБ памяти и, согласно диспетчеру задач, он использовал только около половины этой памяти с нашим приложением, всего около 200 МБ.

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

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

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

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

Источник

Что значит внешний компонент создал исключение

Я создал консольное приложение (32-разрядное) на Visual C++ 2008, производящее математические вычисления. (Операционная среда—Windows 7, 32-разрядная).
В моём приложении происходят выделения динамической памяти с помощью new[] и её последующее удаление (после работы с ней) с помощью []delete.

Вроде бы всем выделениям динамической памяти соответствуют последующие их удаления.
Но после выполнения 370-ой вычислительной итерации в отладчике появляется окно:

Необработанное исключение типа «System.Runtime.InteropServices.SEHException» произошло в Cflculftion.exe

Дополнительные сведения: Внешний компонент создал исключение.

на чём программа и зависает.

Что означает это исключение? Можно ли его как-то обойти или обработать? (В рамках 32-разрядного консольного приложения).
Или же следует поменять какие-то настройки программы?

	От:	Кодт
Дата:	07.11.14 14:43
Оценка:

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

RF>Необработанное исключение типа «System.Runtime.InteropServices.SEHException» произошло в Cflculftion.exe

Где-то в недрах подключенной библиотеки сработала защита памяти.
Каким боком здесь дотнет, непонятно. То ли экзешник на C++/CLI, то ли библиотека дотнетовская подключена к обычному экзешнику.

RF>Что означает это исключение? Можно ли его как-то обойти или обработать? (В рамках 32-разрядного консольного приложения).
RF>Или же следует поменять какие-то настройки программы?

Надо не обходить, а устранить. Это исключение — следствие расстрела памяти.

Включи в студии, в меню Debug > Exceptions. галочки в колонке Thrown, и поймай момент броска.
Потому что, когда исключение должно пересечь границы модулей (границу дотнетовского/неуправляемого кода), оно там ловится и перебрасывается, а уже в вызывающей стороне нет ни try-catch, ни __try/__except/__finally, и поэтому лишь тогда сработал дефолтный панический обработчик.

Даже если исходники модуля, где это всё рухнуло, недоступны, — можно хотя бы понять, на каких входных данных он дал сбой. Может, ошибка в них, а не в модуле.
Ну или если расстрел памяти произошёл чуть раньше, а модуль только наступил на эту мину.

Кстати, советую вместо ручной работы с голыми указателями и new[]/delete[] использовать контейнеры — тот же vector. Меньше шансов что-то напутать и поломать.

	От:	uzhas
Дата:	07.11.14 15:00
Оценка:	35 (1) +2

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

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

RF>>Необработанное исключение типа «System.Runtime.InteropServices.SEHException» произошло в Cflculftion.exe

К>Это исключение — следствие расстрела памяти.

тебя смутил SEH
исключение типа «System.Runtime.InteropServices.SEHException» выстреливает при всех «плюсовых» (в терминах студии) исключениях (std::exception или access violation), они в студии как раз через SEH реализованы.
так что все может быть гораздо прозаичнее:
была написана программа на С++, но в свойствах проекта указали CLI
вылетело плюсовое исключение и вот так себя проявило в виде System.Runtime.InteropServices.SEHException

совет: переделать проект на чисто плюсовый (C++ без CLI и clr)

	От:	Pavel Dvorkin
Дата:	08.11.14 04:01
Оценка:	+1

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

U>исключение типа «System.Runtime.InteropServices.SEHException» выстреливает при всех «плюсовых» (в терминах студии) исключениях (std::exception или access violation), они в студии как раз через SEH реализованы.

Маленькое уточнение : не в студии, а в библиотеке. throw C++ реализован как RaiseException с пользовательским кодом.

U>совет: переделать проект на чисто плюсовый (C++ без CLI и clr)

Совершенно верно. После этого ТС получит просто свой законнный Unhandled Exception. Будет ли ему от этого легче, я правда, не знаю.

	От:	Ops
Дата:	08.11.14 17:32
Оценка:	+2

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

PD>Совершенно верно. После этого ТС получит просто свой законнный Unhandled Exception. Будет ли ему от этого легче, я правда, не знаю.

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

	От:	landerhigh	http://www.blinnov.com
Дата:	09.11.14 22:53
Оценка:

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

Ops>Мне бы точно стало легче, отладка смеси нативного и управляемого кода всегда была для меня чем-то вроде шаманства.

+1. В случае качественного такого расстрела памяти или профессиональной порчи стека в собственно момент перехода на темную сторону (managed) случаются дополнительные спецэффекты.

	От:	Ops
Дата:	10.11.14 02:32
Оценка:

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

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

Ops>>Мне бы точно стало легче, отладка смеси нативного и управляемого кода всегда была для меня чем-то вроде шаманства.

L>+1. В случае качественного такого расстрела памяти или профессиональной порчи стека в собственно момент перехода на темную сторону (managed) случаются дополнительные спецэффекты.

	От:	RussianFellow	http://russianfellow.livejournal.com
Дата:	10.11.14 10:06
Оценка:

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

U>совет: переделать проект на чисто плюсовый (C++ без CLI и clr)

А в каких разделах свойства проекта это можно сделать?

	От:	uzhas
Дата:	10.11.14 11:36
Оценка:

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

RF>А в каких разделах свойства проекта это можно сделать?

	От:	RussianFellow	http://russianfellow.livejournal.com
Дата:	10.11.14 13:23
Оценка:

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

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

RF>>А в каких разделах свойства проекта это можно сделать?

U>http://stackoverflow.com/questions/7232535/build-dll-without-clr-option

Там написано, как сбросить clr .
А как сбросить CLI ?

	От:	RussianFellow	http://russianfellow.livejournal.com
Дата:	10.11.14 13:28
Оценка:

	От:	Кодт
Дата:	10.11.14 13:58
Оценка:

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

RF>Расстрел памяти—это удаление ранее выделенной памяти (delete—new, free—malloc) или же потеря этой памяти вследствие той или иной причины?

Это что угодно.
Самые типичные паттерны:

Это всё — UB, кроме (*), которое не UB, если Base с виртуальным деструктором.

Но можно же и просто расстрелять:

	От:	uzhas
Дата:	10.11.14 14:32
Оценка:

	От:	RussianFellow	http://russianfellow.livejournal.com
Дата:	10.11.14 14:46
Оценка:

У меня в программе динамическая память используется в классе Matrixes, в котором поля n, m—тип int (соответственно число строк и число столбцов).
И есть в этом классе также поле massif типа pldouble, где pldouble—тип long double* .
Память в классе Matrixes выделяется либо с помощью конструктора, либо с помощью функции AllocateMemory. В обоих случаях сперва происходит

а после этого поле massif заполняется нулями:

Есть также и конструктор без параметров—в этом случае

Удаление памяти происходит либо в деструкторе, либо в функции CleanMassif. В обоих случаях происходит проверка, чтобы massif не был равным NULL.
Если massif не равен NULL , то тогда

Если massif равен NULL, то тогда никаких delete не происходит, а просто ставится n = 0 и m = 0 .

Класс Matrixes предназначен для работы с двумерными матрицами. В нём перегружен оператор = для присвоения значений из одной матрицы для другой матрицы, а также есть функции для умножения матрицы на число, сложения матриц, вычитания матриц, транспонирования матриц, нахождения обратной матрицы, перемножения матриц. Больше нигде в моей программе работа с new и delete не происходит (а malloc и free вообще нет в моей программе).

Судя по отладчику, моя программа бьётся на 388-ой (или какой там) итерации в конструкторе класса Matrixes. То есть создаётся впечатление, что программе будто бы не хватает оперативной памяти для выделения массива.

Можно ли как-то исправить это положение?
Ведь до 388-ой итерации программа работает, и работает нормально—всё правильно считает, выдаёт правильные результаты.
Просто на каком-то её этапе выполнения появляется нехватка оперативной памяти.

	От:	Кодт
Дата:	10.11.14 16:15
Оценка:

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

RF>У меня в программе динамическая память используется в классе Matrixes, в котором поля n, m—тип int (соответственно число строк и число столбцов).
RF>И есть в этом классе также поле massif типа pldouble, где pldouble—тип long double* .

Тебе принципиально использовать голый массив голых массивов?
Вот так будет в разы короче

RF>Судя по отладчику, моя программа бьётся на 388-ой (или какой там) итерации в конструкторе класса Matrixes. То есть создаётся впечатление, что программе будто бы не хватает оперативной памяти для выделения массива.

Может быть, и памяти не хватает, из-за фрагментации кучи или из-за прожорливости задачи.
Сделай try <. >catch(bad_alloc) — и узнаешь.

RF>Можно ли как-то исправить это положение?
RF>Ведь до 388-ой итерации программа работает, и работает нормально—всё правильно считает, выдаёт правильные результаты.
RF>Просто на каком-то её этапе выполнения появляется нехватка оперативной памяти.

Если дело действительно в прожорливости задачи, то переписать алгоритм.
Возможно, там возникает куча ненужных объектов: вычислил и выбросил, а не очистил/удалил. Ну так очищай/удаляй.
Возможно, практикуешь ручную очистку вместо того, чтоб возложить её на деструктор. И, соответственно, где-то забываешь очищать (например, при копировании или в сложных выражениях). Перепиши с деструкторами.

	От:	jazzer	Skype: enerjazzer
Дата:	10.11.14 17:16
Оценка:

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

RF>Память в классе Matrixes выделяется либо с помощью конструктора, либо с помощью функции AllocateMemory. В обоих случаях сперва происходит

RF>
RF>затем
RF>

на этом месте у меня вытек левый глаз

Тебе не приходило в голову взять нормальную библиотеку для работы с матрицами и не городить весь этот ад?
Их же навалом, нормальных, оттестированных, без утечек и расстрелов памяти. зачем ты всю эту вышеприведенную ересь пишешь? Грех это, нехорошо.

ЗЫ Имхо, если ты напишешь свои расчеты на Питоне в NumPy, они будут работать быстрее, чем то, чем ты нас тут радуешь.
И падать не будет.

	От:	RussianFellow	http://russianfellow.livejournal.com
Дата:	12.11.14 09:11
Оценка:

Кодт, я сделал почти так, как Вы сказали—в классе Matrix вместо new я ввёл vector (одномерный), который и содержит элементы матрицы.

Программа считает, но сейчас уже она бьётся на 467-ой итерации, а не на 388-ой.
В чём же дело? Может быть, в прожорливости программы—и мне надо будет внимательно смотреть за очисткой ресурсов, за вызовом метода clear у моих векторов?
Или же дело в том, что мне нужно что-то поменять в настройках проекта?

	От:	Кодт
Дата:	12.11.14 10:05
Оценка:

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

RF>Программа считает, но сейчас уже она бьётся на 467-ой итерации, а не на 388-ой.
RF>В чём же дело? Может быть, в прожорливости программы—и мне надо будет внимательно смотреть за очисткой ресурсов, за вызовом метода clear у моих векторов?
RF>Или же дело в том, что мне нужно что-то поменять в настройках проекта?

Никакая очистка ресурсов не поможет, если у тебя алгоритм прожорливый.

Может, ты там мемоизируешь всё подряд без оглядки на то, пригодится ли значение в будущем или нет.
Может, создаёшь очередь вычислений (например, при обходе вширь), которая слишком быстро распухает, быстрее, чем ты её обрабатываешь.
Может, возникает сверхглубокая рекурсия с очень тяжёлыми локальными переменными.
Может быть, эти сверхтяжёлые переменные пухнут не линейно, а всплесками — на 388 и 467 итерациях. Какие-то аналоги проблемы 3X+1, например.

И ещё стопятьсот антипаттернов «как убить всю память, не играя в утечки».

	От:	RussianFellow	http://russianfellow.livejournal.com
Дата:	12.11.14 13:03
Оценка:

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

К>Никакая очистка ресурсов не поможет, если у тебя алгоритм прожорливый.

К>Может, ты там мемоизируешь всё подряд без оглядки на то, пригодится ли значение в будущем или нет.
К>Может, создаёшь очередь вычислений (например, при обходе вширь), которая слишком быстро распухает, быстрее, чем ты её обрабатываешь.
К>Может, возникает сверхглубокая рекурсия с очень тяжёлыми локальными переменными.
К>Может быть, эти сверхтяжёлые переменные пухнут не линейно, а всплесками — на 388 и 467 итерациях. Какие-то аналоги проблемы 3X+1, например.

К>И ещё стопятьсот антипаттернов «как убить всю память, не играя в утечки».

Что Вы посоветуйте мне сделать, чтобы решить эту проблему?

	От:	landerhigh	http://www.blinnov.com
Дата:	12.11.14 13:27
Оценка:

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

К>>И ещё стопятьсот антипаттернов «как убить всю память, не играя в утечки».

RF>Что Вы посоветуйте мне сделать, чтобы решить эту проблему?

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

Источник