Есть C# .NET библиотека. Получает буфер данных, извлекает из него кучку мелких буферов, согласно протоколу передачи. Иногда на вход приходит мусор, в результате чего нарезается много крупных буферов и выдается OutOfMemoryException. В этом случае желательно до этого исключения не доводить, а выдать аварийную диагностику. Прописывать magic number на размеры и число буферов или общее кол-вол памяти, занятое процессом — не хочется. Потом может измениться хост библиотеки, его разрядность. Можно ли как автоматически понять с приемлимой точностью, что вот-вот наступит авария по памяти ?

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

N_P>Есть C# .NET библиотека. Получает буфер данных, извлекает из него кучку мелких буферов, согласно протоколу передачи. Иногда на вход приходит мусор, в результате чего нарезается много крупных буферов и выдается OutOfMemoryException. В этом случае желательно до этого исключения не доводить, а выдать аварийную диагностику.
Ну так и отлавливайте мусор _до_ аллокации памяти. Придёт мусор в виде "много мелких блоков" — что, спокойно обрабатывать должно?

N_P> Прописывать magic number на размеры и число буферов или общее кол-вол памяти, занятое процессом — не хочется. Потом может измениться хост библиотеки, его разрядность. Можно ли как автоматически понять с приемлимой точностью, что вот-вот наступит авария по памяти ?

1. Завести пул больших массивов, переиспользовать.
2. Для проверки использовать MemoryFailPoint.

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

N_P>>Есть C# .NET библиотека. Получает буфер данных, извлекает из него кучку мелких буферов, согласно протоколу передачи. Иногда на вход приходит мусор, в результате чего нарезается много крупных буферов и выдается OutOfMemoryException. В этом случае желательно до этого исключения не доводить, а выдать аварийную диагностику.
S>Ну так и отлавливайте мусор _до_ аллокации памяти. Придёт мусор в виде "много мелких блоков" — что, спокойно обрабатывать должно?

N_P>> Прописывать magic number на размеры и число буферов или общее кол-вол памяти, занятое процессом — не хочется. Потом может измениться хост библиотеки, его разрядность. Можно ли как автоматически понять с приемлимой точностью, что вот-вот наступит авария по памяти ?

S>1. Завести пул больших массивов, переиспользовать.
S>2. Для проверки использовать MemoryFailPoint.

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

N_P>>в результате чего нарезается много крупных буферов и выдается OutOfMemoryException
В .NET 4.5.1 оно тоже воспроизводится? Там есть компактификация LOH

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

N_P>>>в результате чего нарезается много крупных буферов и выдается OutOfMemoryException
Tom>В .NET 4.5.1 оно тоже воспроизводится? Там есть компактификация LOH

Это не ко мне вопрос наверно, к топикстартеру

Проблема в том, что outofmemory может произойти и не по вине managed-кучи, вот тут есть пример.

Вообще, любое исполнение внешнего потока инструкций без проверки валидности — это прямой путь к DOS/повреждению данных. Даже без злого умысла, просто по глупой ошибке.

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

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

N_P>>>>в результате чего нарезается много крупных буферов и выдается OutOfMemoryException
Tom>>В .NET 4.5.1 оно тоже воспроизводится? Там есть компактификация LOH

S>Это не ко мне вопрос наверно, к топикстартеру
Это я ошибся отвечая


S>Проблема в том, что outofmemory может произойти и не по вине managed-кучи, вот тут есть пример.
S>Вообще, любое исполнение внешнего потока инструкций без проверки валидности — это прямой путь к DOS/повреждению данных. Даже без злого умысла, просто по глупой ошибке.

У него как я понял выделяются блоки памяти в managed коде и скорее всего вылазит стандартная проблема с фрагментацией LOH

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

S>>Вообще, любое исполнение внешнего потока инструкций без проверки валидности — это прямой путь к DOS/повреждению данных. Даже без злого умысла, просто по глупой ошибке.
Tom>У него как я понял выделяются блоки памяти в managed коде и скорее всего вылазит стандартная проблема с фрагментацией LOH

Там может быть и норма обработки и фрагментация LOH и банальный выход за 2ГБ на х86 процесс. Как случай ляжет. Обычное дело. Протокол позволяет, по ТЗ такого приходить не должно, филиалы заказчика тычут пальцами в друг-друга "это они виноваты", начальство требует "удовлетворить заказчика".

Нам достаточно отловить опасный момент, выдать диагностику, вывалить данные в брак. MemoryFailTest помог, большое спасибо посоветовавшему.