Pull to refresh

Comments 65

А вы Epic рассказали о найденых у них ошибках?
UPD:
глупый вопрос — просто не проснулся, извиняюсь
В конце статьи есть ответ на ваш вопрос.
Старый NDA не позволяет мне толком ответить на этот вопрос. Скажу только, что Epic знает о существовании анализатора PVS-Studio и что он умеет находить ошибки в программах.
Да божечки, ну сколько можно? Да, они пишут разработчикам и прикладывают список ошибок. Да, они предлагают купить их аналазитор. Да, они делают скидки (а то и отдают нахаляву) для опенсорс проектов.
UFO just landed and posted this here
Комментарий в плюс, карма в минус… Простите-простите, не ною.
В последней строчке следует заменить оператор '-' на оператор '+'.

Там еще и знак неравенства надо сменить.
Position.Y <= Control.Center.Y + BoxSize.Y * 0.5f
Да, точно! Ну да ладно, не буду править статью.
Не странное. Если-бы написали в почту, я бы тихо поправил. А так получится, что комментарий будет не в тему. Вот я и оставил всё как есть. На родном сайте, конечно поправил. Не бойтесь, авторы UE прочитают уточнённый вариант статьи.
Тот кто прочитает комментарий, прочитает и следующие.
Ну и тех, кто прочитает статью, но не будет читать комментарии — гораздо больше.
Странная позиция. Комментарий ведь явно писался с целью улучшить статью. А вы тут — бац! — не буду ничего править, ибо автор останется в дураках. Да не останется он в дураках. У него и цитата приведена, что явно доказывает его комментарий. Плюс, люди же на этом сайте не дураки и если человек внимательно читал статью и комментарии, то он сразу поймёт, что тут творилась история! Ну, а тем, кто выхватил коммент из контекста, уже ничего не поможет, ИМХО.
Ф. М. Достоевский в одном из романов написал
В центре комнаты стоял круглый стол овальной формы

Дотошные ученики указали мастеру на ошибку. Достоевский глянул, пожевал губами и сказал:
-Оставьте так…
Вы знаете, я бы прошёл мимо, если бы не чёткий посыл во всех постах уважаемого Andrey2008. Правда, мне очень нравятся его посты и дело, что он и его команда делает, очень полезное и нужное, его всегда интересно читать. Тем нелепее выглядит ситуация, когда человек, ратующий за досрочное исправление ошибок и неточностей в чужом коде (путём использования статического анализатора), встаёт в позу и говорит — здесь в статье поправлять не будем потому что, дескать, комментарий станет «не в тему». Тем более на родном сайте, неточность, судя по всему поправили. Мне правда не понятна мотивация. Какие-то двойные стандарты получаются, господа.
Это когда Linux стал поддерживаемой UE платформой?
Они то Mac со скрипом поддерживать стали, а под андроид с UDK нельзя было ничего не сделать.
Угу. CryEngine теперь также «поддерживает» Linux — я уже год жду, а воз и ныне там
Спасибо за статью. Хочу обратить внимание на один момент:

Вначале указатель разыменовывается. Ниже этот указатель проверяется на равенство нулю. Это далеко не всегда ошибка. Но это очень подозрительный код, и его надо проверить!
Дело в том, что подобная конструкция может привести к совершенно неожиданным последствиям. Советую почитать статью из блога разработчиков LLVM где эта ситуация разбирается подробно.

Вкратце: оптимизатор компилятора может вырезать код проверки (а следовательно и целую ветвь программы) как «мертвый» код. Одно из соображений, которым может руководствоваться оптимизатор — проверка на NULL разадресованного ранее указателя является избыточной и может быть удалена.

Опасность этой ситуации в том, что она зависит от используемого компилятора (и даже его версии). В любом случае, опасность гораздо выше, чем может показаться.
Ну так компилятор будет прав — если NULL, так значит уже все упало и сюда никак не дошло. Поведение не меняется.
Почитаешь такое, и начинаешь себя вроде минера чувствовать во время написания кода: вроде все делаешь так, а потом посмотрят умные люди на твои труды, и увидят все эти & вместо && и прочее — как раз то, что ты искренне считал нормальным кодом!

Нужно включать еще в конце проверки психологическую помощь программисту: мол, «у Вас на 1000 строк кода всего 18 ошибок, из них 2 — нетривиальные — Вы молодец! Хотите твитнуть это?».
Мы давно уже думаем над тем, как похвалить программиста. Идеи крутятся вокруг чего-то вроде как Вы пишите про 2 нетривиальные, но пока что-то окончательно мысль не сформулировалась.
Главное чтобы пользователи не стали соревноваться в плане самой нетривиальной ошибки :)
Эмммм? Мне кажется, в эту статью народ как раз и приходит, чтобы посмотреть «Хммм, что же они там нетривиального навыдумывали?».
У меня пвс нашел нетривиальную ошибку
int i=k<<-2;

Исход операции неясен.
Так по стандарту сказано, что сдвиг на отрицательные количество бит, равно как и сдвиг отрицательного числа — это UB. Причем именно undefined а не unspecified.

Поэтому это имхо вполне тривиальная ошибка. Если подобное выражение получилось в результате разворачивания макросов (как обычно и бывает), это еще можно назвать таковой, но с натяжкой :)
UFO just landed and posted this here
Серьезно, ребят, напишите кто-нибудь статью с продуманной полной идеей. Лучшие варианты реализуем! :-)
UFO just landed and posted this here
Скорее всего они проверили его первым делом. На официальном сайте, в списке выявленных ошибок, не нашел.
Баннер не надо. Я как-то не смог в бета-тестеры одной программы записаться — они вывесили огромный баннер наверху главной страницы (и без текстовой новости), а мозг его умело вырезал. Может попробовать подвал в шапку перенести «Не прочитали статью и уже есть вопросы»?
Предупреждений V595 довольно много (82 штуки).

Удивительно, как оно (не только UE, но и остальной софт) не падает на каждом шагу с ошибками в выделении памяти, sizeof, работе с нулевыми указателями… Особенно учитывая, что они попадаются не том коде, который вызывается редко, а в основополагающих вещах вроде рассматриваемого LoadMap().
Всё дело в том, что обычно память выделяется, файлы читаются и так далее. А если что-то не то, то вместо адекватного поведения, программа аварийное завершается. Думаю, все наблюдали такую ситуацию: в какой-то программе вы что-то случайно сделали нестандартно, и она вместо «не могу открыть файл» тихо закрывается. Это и есть проявление таких ошибок.
Ничего удивительного — это игровой движок. Нулевые указатели, это в 99% ошибки, когда, скажем система отказалась выделять память. Или отсутствует файл из ресурсов который там должен быть, или еще что-то такое. В таких случаях упасть для игры самое правильное решение. Когда она упадет, стек дамп отправится разработчику, они посмотрят, и поймут что ошибка совсем в другом месте (т.п. пользователь решил подмастерить ресурсы игры или памяти не хватает). А что тогда надо делать? Правильно, падать. Я отнюдь не говорю что такие ошибки не нужно править. Я только пытаюсь пояснить что поправить большинство nullptr ошибок ничего не даст. Если память не выделили, или ресурс не доступен, то проверять это мало как поможет.
С другой стороны, есть куча других ошибок которые было бы очень круто починить, особенно с проверкой «точка в коробке» или что кости анимации в порядке. Такие опечатки действительно приводят к ошибкам вроде размазанных по пол карте персонажей или еще каким-то малоприятным багам.
P.S. Сам разрабатываю уже давно игры на C++ в больших компаниях, с сорсами больших движков и своих собственных.
Вот только тогда вопрос, а зачем ниже по коду проверка указателей? Тогда надо вообще никаких проверок не делать. Разыменовали, упали, profit. Раз есть проверка, значит хотели как-то этот случай обработать.
Ну, не весь код пишется за один раз одним человеком. Я ведь не говорю «это не ошибка». Это конечно же ошибки. Я просто отвечаю на вопрос «как такой софт вообще работает». Кстате, в геймдеве такие ошибки почти всегда чинятся в редакторе уровней, где кто-то забыл присоединить объект к актору, или как-то так. Это как бы реальный баг, а то что упало на отсутствующем наллчеке, ну, это уже следсвие. Конечно, будет клево если перед смертью выдаст в лог чего конкретно не хватает, но, обычно код проверки ошибок это то о чем заботятся очень мало. Тут очень хорошо видна специфика разработки игр, здесь и приоритеты сильно другие. Но это совсем другая история.
С другой стороны, есть куча других ошибок которые было бы очень круто починить, особенно с проверкой «точка в коробке» или что кости анимации в порядке. Такие опечатки действительно приводят к ошибкам вроде размазанных по пол карте персонажей или еще каким-то малоприятным багам.

Тоже хороший пример, кстати, это довольно часто используемая вещь, и с ошибкой, однако же движок как-то работает…
UFO just landed and posted this here
За найденные баги авторам дадут пожизненную подписку на UE?
Прочитал как: «За найденные баги» авторам дадут пожизненно".
Было бы интересно, если бы вам дали протестировать какой-нибудь… скажем, код ядерной электростанции :) Предвижу: «Так, а здесь из-за неправильной скобки выезжают графитовые стержни» или «А здесь из-за выхода за пределы массива разогревается охладитель». Кстати, неплохо было бы и отечественной космической промышленности так помочь — глядишь и спутники бы до орбиты добирались. К вам не обращались из подобных организаций, если не секрет?
Я, конечно, понимаю, что я полный ламер в таких вопросах, но зачем сертифицировать то, что явно не используется? Исправления вносит «сертифицированный» разработчик, а откуда он узнал о том, что исправлять: сам поставил 100 экспериментов, приснилось или подсказал анализатор — какая разница? Да и заказчик никаким образом не сможет достоверно узнал, что анализатор таки использовался (а интернет и так на всех машинах перекрыт, так что код спёрт не будет).
Всё равно нехорошо. Вдруг PSV код отошлёт разработчикам, а то и американцам? Ладно, тут такого нет, но этому «разработчику» может «присниться», что он фрагмент кода отослал на stackoverflow, а там явный баг с системой запуска электростанции, который теперь в паблике.
Мир сертифицированных программ, это другой параллельный мир магии, живущий по иным физическим законом. У нас нет туда доступа. Чтобы посетить этот параллельный мир, нужно много денег и различных магических артефактов, таких как лицензия от ФСБ на секретность и так далее.
И кстати, даже если мы его посетим, то на Хабре всё равно про это не расскажешь и куски кода не опубликуешь. :)
это, конечно, да, но какой-нибудь Фобос-грунт независимый космический аппарат, может быть и получилось бы :)
На АЭС всё до сих пор дублируется релейной защитой, так что всё ок. Ну и вообще для таких задач софт разрабатывается по совсем иным принципам — на Хабре была статья о разработке софта для Шаттла, кажется.

Контрпример: embeddedgurus.com/barr-code/2013/10/an-update-on-toyota-and-unintended-acceleration/
Кстати, один из факторов, из-за которых случилась ЧАЭС, был такой. Выбросы мощности при сработке АЗ-5 на низком ОЗР (что послужило начальным событием аварии) происходили и регистрировались и ранее на нескольких станциях. Но их посчитали глюками измерительной аппаратуры на переходных режимах, да и просто не хотели поднимать шум и начинать исследования. Много лет реакторы работали надежно, пока в одном случае физические параметры аппарата не сложились таким образом, что этот эффект привел к аварии… Сейчас (если вдруг) все эти недоработки устранены.
Это все понятно, но, согласитесь, было бы интересно посмотреть код отдельного модуля, неужели там будет 0 ошибок? Не обязательно АЭС, какие-нибудь критически важные программы регулировки дорожного движения или систем самолета.
Соглашусь, интересно :) И, уверен, какое-то количество ошибок там есть.

Очень рекомендую погуглить на тему этого разбирательства с Тойотой. Там был целый отчет с примерами кода, на коирпый у меня, к сожалению, потерялась ссылка.
Вот там есть ссылка на большой PDF, а еще была краткая выжимка из него страниц в 30, презентация.
> на Хабре была статья о разработке софта для Шаттла, кажется.

Ага, только что-то не находится… Можно обратиться к англоязычным источникам history.nasa.gov/computers/Ch4-5.html ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19930019745.pdf

> Ну и вообще для таких задач софт разрабатывается по совсем иным принципам

Например, согласно "EAL7: Formally Verified Design and Tested", "EAL6: Semiformally Verified Design and Tested", DO-178B/DO-178C. Ну или даже MISRA…
UFO just landed and posted this here
О одной из многочисленных тем писали, что статический анализатор эту дырку не нашёл бы.
Не хотел писать на эту тему, так как в общем то писать не про что. Не смог PVS-Studio найти эту дырку, как и другие анализаторы. Слишком сложная ситуация. Однако, было столько писем, что пришлось краткую заметку написать. Хотя бы для того, чтобы просто ссылкой на письма и комментарии отвечать. На днях опубликую.
Уже давно, в случае ошибки выделения памяти, оператор 'new' генерирует исключение

Есть такой момент, что на игровых консолях исключения обычно выключены.
А зачем тогда операторы throw в коде?
Пример:
HRESULT hr = DataBaseConnection.CreateInstance(__uuidof(ADODB::Connection));
if (FAILED(hr))
{
  FWindowsPlatformMisc::CoUninitialize();
  throw _com_error(hr);
}

Ну, видимо для других платформ…
Sign up to leave a comment.