Comments 26
Вот. Надоедливое возвращение ошибок в ГО, имеет обратную проржииеотную сторону медали: привыкаешь проверять всё и вся.
Делал координатный вычислитель прошлым летом на С++ .. Столько понавтыкал проверок по горшечной привычке, аж сам подивился. Но, заработал сразу и чётко. Никаких нареканий, правок..
Особенно обратная медаль проявляется когда делаешь одни и те-же проверки в функциях, которые вызывают себя по цепочке, и получается, что полезную работу выполняет проверка только в первой функции.
nullable типы нужны для подобного, один раз проверил и все.
уже и пропозал есть https://discourse.llvm.org/t/rfc-optional-a-type-qualifier-to-indicate-pointer-nullability/68004
Не ленитесь. Обработайте указатель, который вернула функция malloc (realloc, calloc, strdup и т.д.). Да, проверка может не пригодится на практике. Возможно, памяти всегда будет достаточно. Но что, вам жалко, что ли? Пишите надёжный код. Не будьте как те программисты из притчи.
Если в ОС используется выделение памяти при обращении (как например в Линуксе), то эти проверки бессмысленны. Потому что фактически память выделяется уже при попытке записать в неё что-то, а malloc всегда успешен, потому что он просто обозначает намерение использовать память.
Ловите ленивого! :)
P.S. Системы разные бывают. Настройки систем бывают разные. Код может заимствоваться в другие приложения для других систем.
P.P.S. Впрочем, продолжайте. Больше подобного кода, больше спрос на статические анализаторы кода :) Спасибо.
сильно зависит от libc и от настроек выделения памяти. Запрос к ядру на выделение новых страниц очень запросто может закончится неудачей. Особенно, если памяти мало, а страницы большие.
Программа как минимум могла бы напечатать "Out of memory".
Или просто поможно было посмотреть в диспетчер задач, Process Monitor, Event Viewer, Performance Monitor, тысячи их. Без всякой выездной бригады. За неумение диагностировать проблемы приходится платить.
Да и толку особо нет. Я проверю, я молодец, а кто-нибудь из моих зависимостей - не проверит, опять упадём, что делать будем? Опять бригаду высылать?
P.S.
Вообще я всеми руками за то, чтобы всё проверять и писать сообщения об ошибках везде, где только можно. Включая malloc. Просто для malloc это имеет наименьший из всех смыслов.
P.P.S.
Вообще, при анализе проблем в закрытых системах, "выездные бригады" неизбежны. Я не видел еще никого, кто бы смог уйти от этого при работе над такими системами.
ну так в стектрейсе или дампе это было бы видно сразу, но их не дают. Пришлось им ехать в командировку и проверять это на месте. С другой стороны некоторые ос приучили что памяти не может не быть, как быть в таком случае. Вот совсем свежий пример, xbox - памяти физически нет (ну так может 10-15кб осталось, это мы уже тестами репро такое накрутили), малок вернул чтото, и только при попытке записать туда получаем краш, а это получалось через несколько фреймов только. И был гейзенбаг, потому что в 99% случаев ОС успевала чтото освободить и запись не крашилась
ну так в стектрейсе или дампе это было бы видно сразу, но их не дают
Ничего из предложенного мной не требует ни стектрейса, ни навыков программирования, ни даже пересылки данных при желании. Только пошаговые инструкции к исполнению.
В целом, как я и сказал: залогировать можно и нужно, но анализ обозначенной в статье проблемы не требует выездной бригады). Любой монитор ресурсов показал бы out of memory.
То, что у компании есть деньги на оплату выездной бригады и нет денег на настройку мониторинга ресурсов на железе - это оч интересно конечно)
Вообще-то программа могла и диск использовать
Мне нравится как в redis сделали, просто написали небольшую обёртку над malloc. С одной стороны никогда не проверяют возвращаемый результат от malloc, с другой, в случае ошибки эта обёртка и напишет что-то вроде "Out of memory" (ну и то, что один malloc можно заменить другим тоже плюс).
Не ленитесь. Обработайте указатель,
Ленитесь и не обрабатывайте указатель! И тогда вас отправят в командировку зарубеж. Профит.
В реальности в сложных системах в первую очередь проверяется общее состояние системы: наличие памяти, свободного места, загруженность процессоров и тд. Данная бага легко определяется по наличию корки и информации в ней: место, где упало gdb -> смотрится код и видится malloc сразу становится всё понятно. Т.е такая проблема сразу очевидна, поэтому скорее всего ваша притча немного мутировала под вашу конкретную тему.:)
А так, да, могут быть очень хитрые проблемы с выделением динамической области памяти. Например, на моей прошлой работе мне как-то дали багу. Никто не мог её пофиксить. И я смотрю, ну должно же работать. Вкратце, там была app под Windows, компилятор и ide от Microsoft, VS. Через какое-то время обнаруживаю, что оказывается: не работает тольков релиз сборке (9/10 попыток работает нормально), а в дебаге всё отлично, ну и сразу стало понятно надо искать багу с памятью. И точно, кто-то запушил веделение памяти, а дальше по коду проверялось нуль там или нет, если нуль - инит, а если нет, то интерпретируем как обьект. В дебаге выделяется память и заполняется нулями, а в релизе там мусор. Поэтому бага то всплывала, то нет (а всё зависит от того, что лежит в памяти). Помню, гордился собой (про себя), что решил проблему. Приятные воспоминания.
Проклятие VS2010! У меня наверно сотни часов ушли на вылавливание этих багов ленивых проггеров одном проекте на работе. Разное поведение и при отладке и релизи в принципе не приветствуется, но тут вроде как UB
Одно из двух проклятий. Второе - то, что в нетривиальном классе унаследованом от непустого класса базовый класс не инициализировался при инициализации значением в релизе(вот тут строгое несоблюдение стандарта).
Обе "фичи" - упертое желание разрабов поддерживать какой-то легаси код сторонних библиотек. Причем насколько известно, второе сломало код одного из подразделений самого майкрософт. Было много раз заявлено как баг, но всегда были отказы в исправлении.
Расскажите подробнее! А что такое "запушил"?
"дальше по коду проверялось нуль там или нет, если нуль - инит, а если нет, то интерпретируем как обьект."
Ничего не понятно, но очень интересно. Можете на псевдокоде накидать пример?
alloc malloc plati naloc
Клиент же тем делом всё больше раздражается.
Если программа упала молча - это проблема программы. Если написала "out of memory" - проблема пользователя.
В рамочку и на стену.
Притча о нулевом указателе для ленивых C программистов