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

Часть людей считает, что надо пытаться обрабатывать все виды runtime ошибок, в т.ч. и OOM ситуации. Другие считают, что с OOM всё равно мало что можно сделать и лучше дать приложению просто упасть. На стороне второй группы людей ещё и тот факт, что дополнительная логика обработки OOM с трудом поддаётся тестированию. А если код не тестируется, то почти наверняка он не работает.

Я полностью согласен с тем, что не стоит реализовывать логику обработки ошибок которую вы не собираетесь тестировать. Почти наверняка она ничего не улучшит, а может и того хуже — всё испортит.

Вопрос о том надо ли пытаться обрабатывать OOM ситуации в библиотеках/приложениях является противоречивым и мы не будем его здесь касаться. В рамках данной публикации я лишь хочу поделиться опытом того как можно тестировать реализованную логику обработки OOM ситуаций в приложениях написанных на C/C++. Разговор будет идти об операционных системах Linux и macOS. Ввиду ряда причин, Windows будет обойдён стороной.

Тема изъезжена и уже не мало копий было сломано из-за неё. Так или иначе люди продолжают задаваться вопросом о том может ли приложение написанное на C/C++ не упасть после разыменования нулевого указателя, например. Краткий ответ — да, даже на Хабре есть статьи на сей счёт.

Одним из наиболее частых ответов на данный вопрос является фраза "А зачем? Такого просто не должно случаться!". Истинные причины того почему люди продолжают интересоваться данной тематикой могут быть разные, одной из них может быть лень. В случая когда лениво или дорого проверять всё и вся, а исключительные ситуации случаются крайне редко можно, не усложняя кода, завернуть потенциально падающие фрагменты кода в некий try/catch который позволит красиво свернуть приложение или даже восстановится и продолжить работу как ни в чём не бывало. Наиболее ненормальным как раз таки может показаться желание снова и снова ловить ошибки, обычно приводящие к падению приложения, обрабатывать их и продолжать работу.

Итак попробуем создать нечто позволяющее решать проблему обработки SIGSEGV-подобных ошибок. Решение должно быть по максимуму кроссплатформенным, работать на всех наиболее распространённых десктопных и мобильных платформах в однопоточных и многопоточных окружениях. Так же сделаем возможным существование вложенных try/catch секций. Обрабатывать будем следующие виды исключительных ситуаций: доступ к памяти по неправильным адресам, выполнение невалидных инструкций и деление на ноль. Апофеозом будет то, что произошедшие аппаратные исключения будут превращаться в обычные C++ исключения.

На заре эры Хабрахабра мне посчастливилось поучаствовать в разработке непростого, по тем временам, устройства. Это была небольшая 10-ти слойная плата битком набитая электронными компонентами.

После производства опытной партии обнаружилась серьёзная проблема. Была найдена ошибка из-за которой не работала NAND память. Поскольку NAND был единственным вариантом для загрузки, устройство, не смотря на работоспособность остальных компонентов, оказалось абсолютно бесполезным.

Необходимо было решить проблему. При нахождении ошибок в программе, на неё можно бесконечно накладывать патчи. С аппаратными ошибками «патчи» в виде разрезанных дорожек и перемычек не всегда помогают справиться. Что же делать, если под BGA чипом перепутаны два ряда выводов?

Однажды в печатной продукции была обнаружена ошибка: опечатка в доменном имени. Времени переделывать что-либо уже не было, так как продукция уже распространялась.

Обычно в этом случае просто регистрируется доменное имя с опечаткой и настраивается перенаправление, но не тут-то было. Из-за ошибки первая половина доменного имени была латинской, вторая — кириллической. Выглядело это примерно так: «hello-мир.ru».

Несмотря на то, что многие считают наши государственные стандарты, касающиеся ЕСКД и ЕСПД устаревшими, конструкторскую и программную документацию необходимо выполнять в соответствии с ними.

Когда я был совсем молодым «специалистом» я с унынием наблюдал за тем, как в Microsoft Office пишутся технические условия, программы и методики испытаний. Порой эти документы очень сложные и длинные. Наиболее пугающими были основные надписи, помещённые в колонтитул. Они никак не соответствовали ГОСТ 2.104. В простонародье их называют «рамками». Они были ужасны. Я не видел, чтобы кому-то удавалось сделать их правильно. Плавали размеры, толщины линий. Это было видно даже без линейки.

Прочитав однажды пост [1] про успешный проброс видеокарты в виртуальную машину я подумал, что неплохо бы мне завести себе такую рабочую станцию.

При разработке кроссплатформенного программного обеспечения часто возникают проблемы с его тестированием. Всю свою работу я выполняю исключительно под Linux'ом, при этом конечный пользователь работает исключительно в операционной системе (ОС) Windows. Можно было бы использовать VirtualBox, например, но когда нужно проверить работу модулей использующих OpenGL или CUDA возникают серьёзные проблемы. Dual Boot как вариант даже не рассматриваю. Получается, что, так или иначе, мне приходиться использовать второй компьютер, который просто не куда поставить. При этом большую часть времени он простаивает без дела. Получается крайне не эффективная, с точки зрения использования ресурсов, схема.

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

1. Операционная система Windows 7 (далее Windows);
2. Набор программного обеспечения использующего DirectX, OpenGL и CUDA;
3. Высокоскоростное, локальное, отказоустойчивое хранилище размером порядка 10 Тб;
4. Механизм резервного копирования и восстановления всей системы;
5. Периодическое автоматическое резервное копирование пользовательских данных.

Многие могут подумать: «Причём же тут виртуализация?». Проблема в том, что Windows, по моему личному мнению, не отличается высокой надёжностью. Зачастую конечными пользователями системы являются не особо квалифицированные люди, в следствии чего на компьютер попадает зловредное ПО, которое может уничтожить все данные на всех накопителях. При этом необходимо чтобы бэкап хранился локально, но уничтожить его было не возможно. Организация большого и быстрого хранилища данных так же не является тривиальной задачей. Так или иначе, было решено запускать Windows в среде виртуальной машины (ВМ).