LINUX.ORG.RU

Почему надо проверять malloc на NULL

 , ,


1

3

Вообще выделение памяти проверять.

А вот потому что:

#include <stdio.h>
int main()
{
  unsigned char *a = NULL;
  int b = 0;
  unsigned long n = (unsigned long)&b;
 
  printf("b = %d, n = %lu\n",b,n);
  a[n]=1;
  printf("b = %d\n",b);
  return 0;
}

Запуск

$ gcc nullptr.c -o nullptr
$ ./nullptr 
b = 0, n = 140731726099148
b = 1

Запускалось в 64-битном (x86_64) Linux. Как видно, никаких сегфолтов и прочих ошибок. Конечно, адрес в районе 127 Тб в примере далеко за пределами доступного почти на всех компьютерах, но нет никаких гарантий, что на какой-то системе с каким-то компилятором и настройками среды значение не окажется более доступным. Могут быть и другие архитектуры (32-битные например), если запускать от root'а, то в начало может быть разрешена запись и там иметься память процесса. Или ещё какие-то варианты.

shdown, monk, liksys, Xenius - я думаю вам понравится. Пример сочинился по ходу чтения обсуждения Вышло издание 2,92 книги «Программирование: введение в профессию» А. В. Столярова (комментарий)

★★★★★

Последнее исправление: anonymous_incognito (всего исправлений: 1)
Ответ на: комментарий от eao197

Эту самую целостность тестировать не нужно?

В том чем конкретно я занимаюсь - ещё как нужно. Всё критичное имеет TxLog (WAL) с маркерами конца транзакций и checksums. Определённую проблему вызывает SHM которую нельзя оставлять в произвольном состоянии, но при некоторой аккуратности с этим можно бороться.

bugfixer ★★★★★
()
Последнее исправление: bugfixer (всего исправлений: 1)
Ответ на: комментарий от eao197

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

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

monk ★★★★★
()
Ответ на: комментарий от MKuznetsov

а ничего так что если памяти нет у malloc (он NULL вернул), то с большой вероятностью она сейчас кончится и на стеке ?

В норме стек резервируется при запуске программы и никак с динамической памятью не пересекается. malloc не может дать память за счёт стека, стек не может вырасти за счёт неиспользуемой динамической памяти. Если malloc вернул NULL, то можно делать всё, что не запрашивает динамическую память.

monk ★★★★★
()
Ответ на: комментарий от monk

Если malloc вернул NULL, то

если это не игры с ulimit, то например упахана память. Аллокатор порывшись в своих ссылках и структурах пришёл к выводу что ппц. Повезло что он вообще что-то вернул. Далее ни на один указатель нельзя полагаться.

философский вопрос «ваши действия при ядерном взрыве справа». Проверки malloc на NULL как-раз в этом стиле

MKuznetsov ★★★★★
()
Ответ на: комментарий от monk

В норме стек резервируется

NULL от malloc это НЕ НОРМА. Настолько не норма, что её хрен корректно проверишь. Тут эрланговский метод «падаем, авось поднимет кто-нибудь» наиболее разумен

MKuznetsov ★★★★★
()
Ответ на: комментарий от MKuznetsov

если это не игры с ulimit, то например упахана память.

Не обязательно. Может, это эвристика оверкоммита решила не давать тебе память.

К примеру, машина с 4GB памяти, свободно 2 гига. Свопа нет, настройки оверкоммита по дефолту (vm.overcommit_memory = 0, vm.overcommit_ratio = 50). Ты запросил malloc’ом 10 GB. malloc() вернет NULL. Память не упахана, аж 2 гига свободно.

bigbit ★★★★★
()
Ответ на: комментарий от MKuznetsov

Тут эрланговский метод «падаем, авось поднимет кто-нибудь» наиболее разумен

В нынешнем мире я видел СУБД, которые также реагировали на недостаток места на диске. Так что я уже ничему не удивляюсь. А WindowsBackup на любую файловую ошибку предлагает выгружать все терабайты заново.

monk ★★★★★
()
Ответ на: комментарий от MKuznetsov

ну так и я об этом

На Solaris нет оверкоммита. И NULL из malloc вполне штатная ситуация, когда именно твоему процессу не хватило памяти. При этом процесс может продолжать работать (например текстовый редактор не смог получить блок памяти для открытия ещё одного файла, но может продолжать работать с теми, что есть).

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

monk ★★★★★
()
Ответ на: комментарий от monk

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

к слову пришлось :-) в редакторах как правило этого не требуется. Файлы либо закрыты, либо хоть и открыты но все буферы сброшены. Изменения фиксируются в журналах (не только ФС, но и собственных). Упоганить редактируемый файл или потерять «мучительно набитое за 15 минут» даже отключением питания это надо постараться и должно сильно не повести. Может с видео-редакторами как-то иначе.

только в офф-топике такое видел и то не в лидирующих продуктах. Вот там лёгким движением рубильника открытый файл может заполнится нулями.

MKuznetsov ★★★★★
()
Ответ на: комментарий от MKuznetsov

либо хоть и открыты но все буферы сброшены

В смысле? Вот запустил я Emacs, что-то подготовил в *scratch*, попытался открыть файл, чтобы добавить в него набранное, и внезапно закончилась память. Где смотреть набранный текст? После перезапуска Emacs в *scratch* его нет.

monk ★★★★★
()
Последнее исправление: monk (всего исправлений: 1)
Ответ на: комментарий от MKuznetsov

Вот там лёгким движением рубильника открытый файл может заполнится нулями.

Проблема не в том, что нулями, а в том, что текущая работа пропадает. В оффтопике у меня выработалась привычка тыкать Ctrl-S пока думаю, что дальше писать. В MSDOS введённые данные терялись только если свет выключили.

monk ★★★★★
()
Ответ на: комментарий от monk

В смысле? Вот запустил я Emacs, что-то подготовил в *scratch*, попытался открыть файл, чтобы добавить в него набранное, и внезапно закончилась память. Где смотреть набранный текст? После перезапуска Emacs в *scratch* его нет.

мне вот кажется что это проблема Emacs, нет ? В SlickEdit или (в офтопе) клятый-ворд или Notepad++ даже при сбое питания (не чтобы память закончилась, а вообще всё) то немногое пропадает. Если ФС вообще уцелела, то можно «восстановить сесcию».

MKuznetsov ★★★★★
()
Ответ на: комментарий от monk

В норме стек резервируется при запуске программы

Но, ведь в Линуксе физическая память под стек не выделяется при запуске программы? Там вобще как-то можно до выполнения важной части программы заполнить стек страницам, чтобы программа не получила SIGSEGV от того, что ядро не нашло страницу?

mky ★★★★★
()
Ответ на: комментарий от MKuznetsov

Проверки malloc на NULL как-раз в этом стиле

Ну может я больной и место под кэшированные данные через malloc выделяю, получу NULL - освобожу что-нибудь из самого старого?

no-dashi-v2 ★★★★
()
Ответ на: комментарий от MKuznetsov

В SlickEdit

Это в каком дистрибутиве такой есть?

или (в офтопе) клятый-ворд

Вот ворд меня и приучил к Ctrl-S. Потому что автосохранение раз в 5 минут и если сдохло с середине автосохранения, то автосохранение нерабочее.

Если ФС вообще уцелела, то можно «восстановить сесcию».

Если файл сессии целостный, то да.

monk ★★★★★
()
Ответ на: комментарий от mky

Там вобще как-то можно до выполнения важной части программы заполнить стек страницам

Да.

#define STACKSIZE 100500

int seizestack()
{
   volatile int a[STACKSIZE];
   for(int i; i < STACKSIZE; i+=1024) a[i] = 1; // пишем в каждую страницу
}

int main()
{
   seizestack();
}
monk ★★★★★
()
Последнее исправление: monk (всего исправлений: 1)
Ответ на: комментарий от mky

чтобы программа не получила SIGSEGV от того, что ядро не нашло страницу?

Она не получит SIGSEGV, в этот момент OOM killer кого-то убъёт. Может эту программу, может какую-то другую.

monk ★★★★★
()
Ответ на: комментарий от monk

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

Не-не-не, вопрос был не про проектирование с расчетом на сбои. А именно про тестирование. Вот запроектировал ув.тов.bugfixer некий процесс с контрольными точками, двух-фазным подтверждением, write-ahead-log и вот этим вот всем, запрограммировал. Тестировать ему всю эту кухню же нужно?

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

PS. Предлагаю вообще не рассматривать тезис о том, что под Linux-ом malloc не может возвращать NULL. Поэтому что если от него отталкиваться, тогда и предмета для разговора нет.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

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

Я так понимаю, он предполагает, что для тестирования придётся заставить ОС не выдать память, а это сложно. Но никто не мешает для тестирования подложить свой malloc, который выдаст NULL на нужный запрос.

Предлагаю вообще не рассматривать тезис о том, что под Linux-ом malloc не может возвращать NULL.

Не «не может», а «может не». Под Linux реально надо тестировать на получение kill -9 в произвольный момент времени. Но проверять на NULL всё равно надо, так как если прилетел NULL и не проверен, то можно сначала затереть себе что-нибудь нужное, а только потом упасть.

monk ★★★★★
()
Ответ на: комментарий от eao197

Тестировать ему всю эту кухню же нужно?

Можно я влезу в ваш междусобойчик? Конечно нужно.

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

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

PS. Предлагаю вообще не рассматривать тезис о том, что под Linux-ом malloc не может возвращать NULL. Поэтому что если от него отталкиваться, тогда и предмета для разговора нет.

Да конечно NULL прилетает. И самый простой способ это увидеть (по крайней мере у нас самый частый) - упереться в 4GB в 32битном процессе.

bugfixer ★★★★★
()
Ответ на: комментарий от monk

Я так понимаю, он предполагает, что для тестирования придётся заставить ОС не выдать память, а это сложно.

Нет, я его слова понял не так и, имхо, ниже он сам уточняет:

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

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

eao197 ★★★★★
()
Ответ на: комментарий от eao197

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

Бинго!

bugfixer ★★★★★
()
Ответ на: комментарий от bugfixer

Количеством сценариев.

Еще году в 1994-ом на одной из лекций в универе нам, тогдашним студентам, рассказали, что сложность ПО в 1970-е уже выросла настолько, что проверять все возможные ветки исполнения кода на всех возможных входных данных стало утопией.

Отладить свой reliable persistence я могу один раз, и дальше следовать парадигме «ничего не происходит пока чек-поинт не пройден».

Осталась самая малось – проконтролировать все чекпоинты и что эта самая парадигма нигде не нарушается.

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

В 99% процентах случаях такой «хендлинг ошибки по своему» будет всего лишь return-ом наверх. И это гораздо лучше, чем безусловный abort сразу здесь и сейчас.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Осталась самая малось – проконтролировать все чекпоинты и что эта самая парадигма нигде не нарушается.

Вполне подъёмная задача, на самом деле.

В 99% процентах случаях такой «хендлинг ошибки по своему» будет всего лишь return-ом наверх.

Ну, в пределе это ничем не отличается от abort(), только дороже. А вот если оно (stack unwinding) где-то действительно останавливается - вот тогда самый настоящий f-fest как раз и начинается, во всех смыслах…

И это гораздо лучше, чем безусловный abort сразу здесь и сейчас.

Очень и очень спорное утверждение.

bugfixer ★★★★★
()
Последнее исправление: bugfixer (всего исправлений: 1)
Ответ на: комментарий от bugfixer

Вполне подъёмная задача, на самом деле.

Особенно если заниматься самовнушением :)

Ну, в пределе это ничем не отличается от abort(), только дороже.

Это очень и очень спорное утверждение, ув.коллега.

Если вы пишете конкретную программулину для решения конкретной задачи и ваша предметная область позволяет использовать «fail-fast, restart quickly» во все поля, то OK. Вызов abort все очень и очень серьезно упрощает.

Но если вы делаете библиотеку (условный libcurl), которая используется в разных проектах и разных условиях, то abort на NULL из malloc-а – это даже не мовитон, это диверсия.

Аналогично и про проекты, для которых «fail-fast, restart quickly» так себе вариант. Например, прокси-сервер, который держит 100K одновременных соединений (часть из которых длительные). При обработке одного из коннектов NULL из malloc-а и падение всего сервера с последующим переподключением всех клиентов… Ну такое себе.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Но если вы делаете библиотеку (условный libcurl), которая используется в разных проектах и разных условиях, то abort на NULL из malloc-а – это даже не мовитон, это диверсия.

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

Аналогично и про проекты, для которых «fail-fast, restart quickly» так себе вариант. Например, прокси-сервер, который держит 100K одновременных соединений (часть из которых длительные). При обработке одного из коннектов NULL из malloc-а и падение всего сервера с последующим переподключением всех клиентов… Ну такое себе.

Крайне неудачный пример. Сервер который начинает реджектить все запросы куда как менее полезен чем тот который после переподключения выдаёт что-то вменяемое.

bugfixer ★★★★★
()
Ответ на: комментарий от bugfixer

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

И как, например?

Мы делаем продукт на базе условного libcurl и когда продукт оказывается в условиях нехватки памяти он тупо падает при попытке подконектится к очередному узлу просто потому, что условный libcurl вместо того, чтобы сказать «не могу, нет памяти», а мы бы сказали пользователю «не сейчас», тупо рушит все через abort.

Как на такой базе делать вообще что-то, что не загнано в рамки жестких спецификаций – такая-то ОС, такое-то железно, ничего больше там нет, кроме нашего ПО (+ оговоренный список системных сервисов)?

Сервер который начинает реджектить все запросы куда как менее полезен чем тот который после переподключения выдаёт что-то вменяемое.

А кто вам сказал, что после проблемы в одном подключении будут режектиться все последующие?

eao197 ★★★★★
()
Последнее исправление: eao197 (всего исправлений: 1)
Ответ на: комментарий от monk

заставить ОС не выдать память, а это сложно

Это тривиально. В только в этом ITT-треде простейший способ упоминался 100500 раз.

r--r--r--
()
Последнее исправление: r--r--r-- (всего исправлений: 1)
Ответ на: комментарий от bugfixer

Сервер который начинает реджектить все запросы куда как менее полезен чем тот который после переподключения выдаёт что-то вменяемое.

Но в этой же дискуссии сравниваются два других сервера - сервер, который реджектит новые подключения и сервер, который упал на середине обработки существующих 100500 подключений, потому что ему не хватило памяти на 100501-ое.

r--r--r--
()
Ответ на: комментарий от r--r--r--

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

monk ★★★★★
()
Ответ на: комментарий от eao197

А кто вам сказал, что после проблемы в одном подключении будут режектиться все последующие?

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

К тому-же с фанатизмом «всегда проверяём malloc на NULL» вы этот указатель будете проверять примерно трижды. Каждый malloc, один и тот-же указатель. Не веришь - открой любимый эталонный проект и сунь в отладчик: проверяем malloc на NULL, проверяем функцию которая вызвала malloc на NULL и её родителя тоже. malloc, foo_alloc, foo_simple_alloc...

MKuznetsov ★★★★★
()
Ответ на: комментарий от MKuznetsov

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

Так что нет, вести с вами конструктивный разговор нет смысла.

eao197 ★★★★★
()
Ответ на: комментарий от MKuznetsov

Сервер всё одно штатно не работает - бросает соединения одно за другим.

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

Ничего не выиграно.

А если подумать головой?

r--r--r--
()
Ответ на: комментарий от r--r--r--

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

у (процесса)сервера просто нет памяти. кончилась

Раз уж все подключения слиты в монолит, значит так надо, они сильно взаимосвязаны и используют общую память. Памяти нет прямо сразу у всех. Её нехватает всем сразу, всему процессу.

MKuznetsov ★★★★★
()
Ответ на: комментарий от eao197

Я бы мог здесь рассказать пару случаев из практики, но как-то мы уже с вами общались,

помню, помню...вы тот самый человек, который для каждого таймера заводил по отдельному треду и считал что это ЗБС..Общение конечно-же не выдалось

MKuznetsov ★★★★★
()
Ответ на: комментарий от MKuznetsov

Её нехватает всем сразу, всему процессу.

Всему процессу хватает памяти для обработки N клиентов. Всему процессу не хватает памяти для обработки N+M клиентов, где M - натуральное (целое, положительное, больше нуля) число.

r--r--r--
()
Ответ на: комментарий от MKuznetsov

вы тот самый человек, который для каждого таймера заводил по отдельному треду и считал что это ЗБС

Вы не правильно помните.

eao197 ★★★★★
()
Ответ на: комментарий от r--r--r--

В рассмотрение нужно включить еще и ситуации, когда:

  • на сервере достаточно памяти, чтобы справляться со «средними» клиентами, но бывают особо выдающиеся, обслуживание коннекта для которых начинает жрать память;
  • в реализации сервера могут быть ошибки, из-за которых для обслуживания очередного клиента вдруг вместо 4K запрашивается 4Gb (или 44Gb, или 444Gb), и этот запрос ожидаемо обламывается с NULL-ом. Но это не значит, что подобная ошибка обязательно встретится при обслуживании других коннектов.

Тогда все станет еще более жизнерадостным.

eao197 ★★★★★
()
Последнее исправление: eao197 (всего исправлений: 1)
Ответ на: комментарий от eao197

Я думаю, здесь некоторое недопонимание между участниками дискуссии.

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

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

И вы правы, и то, что вам говорят, правильно. Но лично мне непонятно, зачем тогда усложнять себе жизнь и пытаться восстановиться после […].

shdown ★★
()
Последнее исправление: shdown (всего исправлений: 3)
Ответ на: комментарий от eao197

В рассмотрение нужно включить еще и ситуации, когда:

ни надо никого включать.

Общий случай, где-то внутри процесса malloc вернул NULL (hip`а нет, память фрагментирована и мелкие free() не спасут, если embed то вот вот и стек исчерпается) , что и как ему делать ? где будешь ловить и как обрабатывать ошибку.. как будешь проверять ??

MKuznetsov ★★★★★
()
Ответ на: комментарий от shdown

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

Вообще-то я говорю не это.

Повторю еще раз: есть класс задач, в которых NULL из malloc-а должен вести к немедленному abort-у и это лучшая реакция.

Есть класс задач, в которых так быть не должно в принципе. Там следует получив NULL из malloc-а вернуть ошибку наверх, чтобы разбирались выше. Даже если выше все равно вызовут abort, это ничего не меняет для того куска кода, в котором malloc вернул NULL – этот кусок кода не уполномочен принимать такие решения (выше ув.тов.monk правильно сказал)

И есть целый раздел в разработке софта – написание библиотек – в котором вы вообще не имеете права звать abort после NULL из malloc-а. Просто потому, что заранее не знаете в каком контексте ваша библиотека будет использована.

А раз есть такое многообразие, то утверждать что после NULL из malloc-а только abort и никакой другой жизни нет… Ну не знаю, цензурных слов у меня уже не хватает для описания столь глубокого заблуждения.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

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

В библиотеках нельзя звать abort после NULL из malloc-а, потому что библиотека может использоваться в контексте задачи из вышеупомянутого класса.

Из этого делается вывод, что «есть такое многообразие».

А какие, собственно, задачи лежат в этом классе? Или, скорее, к каким ОС будут прибиты эти «задачи»?

shdown ★★
()
Последнее исправление: shdown (всего исправлений: 2)
Ответ на: комментарий от shdown

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

Я привел пример в единственном числе, его можно найти выше по обсуждению.

Еще раньше, емнип, ув.тов.monk привел пример с текстовым редактором (может быть и не он, но мне лень искать).

Т.е. «примеры» во множественном числе есть.

Из этого делается вывод, что «есть такое многообразие».

Нет, не из этого.

А какие, собственно, задачи лежат в этом классе?

Вы с какой целью интересуетесь?

eao197 ★★★★★
()
Ответ на: комментарий от shdown

Базы данных, к примеру.

У оракла объём используемой памяти можно задать в конфигурации. Лет 12 назад я тестировал его поведение на минимальном объёме доступной памяти - мне надо было держать в целом не нужный инстанс на рабочем ноутбуке. Оракл прекрасно отрабатывал ситуации с ограничением по памяти - я легко нашёл границу объёма, когда инстанс запускался, но не мог отработать запросы. Ошибки, что он возвращал клиенту, не всегда корректно указывали на проблему, но в остальном поведение было просто идеальным.

Помимо БД, есть ещё гигантский спектр задач телекома и прочего, где "просто падать" вообще нельзя, так как отказ в обслуживании текущим клиентам / пользователям - это удар по технологическим процессам, репутации и "бизнесу" в самом широком смысле этого слова. В таких сферах между "мы гарантированно обслуживаем N запросов" с одной стороны и "мы в целом вроде нормально работаем, но если данных много, то временно прекращаем работать" лежит гигантская пропасть.

к каким ОС будут прибиты эти «задачи»?

А вот ОС тут вообще не важны. Такие задачи могут даже на голом оборудовании выполнятся.

r--r--r--
()
Последнее исправление: r--r--r-- (всего исправлений: 1)
Ответ на: комментарий от r--r--r--

Дополню ещё одним пунктом:

Для целого ряда программ в случае отказа хорошо бы выдавать вменяемую диагностику проблемы вместо суровосибрского killed от OC в терминале.

r--r--r--
()
Ответ на: комментарий от eao197

А раз есть такое многообразие, то утверждать что после NULL из malloc-а только abort и никакой другой жизни нет… Ну не знаю, цензурных слов у меня уже не хватает для описания столь глубокого заблуждения.

Вы же сейчас меня имеете в виду? :) Мои личные наблюдения таковы: без тени преувеличения я видел тысячи OOM корок в проде, и из них только в единичных случаях можно было бы что-то предпринять чтобы заставить процесс дохромать до следующего штатного рестарта. И я подчёркиваю - при этом процесс работал бы в сильно кастрированном режиме. СтОит ли оно того геморроя - как по мне так cost / benefit просто зашкаливает. Я не сомневаюсь что для целого класса задач и ситуаций это не так, но мой личный опыт именно таков.

bugfixer ★★★★★
()
Ответ на: комментарий от bugfixer

Я не сомневаюсь что для целого класса задач и ситуаций это не так, но мой личный опыт именно таков.

Хоть так. Это как с ремонтом/лечением. Где-то принято лечить сколько возможно. Где-то принято при любом сбое сразу пристреливать. И обосновывают тем самым cost / benefit.

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

monk ★★★★★
()
  • Markdown
Пустая строка (два раза Enter) начинает новый абзац. Знак '>' в начале абзаца выделяет абзац курсивом цитирования.
Внимание: прочитайте описание разметки Markdown.
Используйте Ctrl-Enter для размещения комментария