Comments 40
Тут же в мыслях мелькнул желтушный заголовок…
«PVS-Studio спасает людей от заложенных в ПО убийц!»
«PVS-Studio спасает людей от заложенных в ПО убийц!»
"Наёмный баг-убийца..."
даже PVS не сможет найти подобные ошибки :)
Подобные может и нет, но вы посмотрите сколько и в каких проектах находили дичайшие опечатки которые в каком-то из набороа параметров могли выстрелить и приводили или к порче данных или к краху программы или к неопределенному поведению, так что доля истины в моем заголовке есть.
да ладно, использование булеана в виде "x=x+1" должно же отлавливать
В С++ если сделать так:
bool a = x;
a = a + 1;
Всё будет хорошо.
А если сделано так, то тут всё равно нельзя ругнуться:
byte a = x;
a = a + 1;
Слишком много ложных срабатываний будет.
bool a = x;
a = a + 1;
Всё будет хорошо.
А если сделано так, то тут всё равно нельзя ругнуться:
byte a = x;
a = a + 1;
Слишком много ложных срабатываний будет.
Читайте года этого бага. В чистом С, без плюсов, булевых переменных и сейчас нет, только инты(байты, слова и т.п.), и ноль или не ноль.
Заголовок и набор картинок дает основание предполагать, что пост изначально был предназначен для публикации на Пикабу.
UFO just landed and posted this here
А ещё автор измеряет дозу радиации в Рентгенах, хотя накопленные дозы измеряются в Греях, а в рентгенах измеряются экспозиционная доза. Экспозиционные дозы люди порой переживали и больше, чем 1000 рентген. Вот этот чел получил 300 000 рентген и остался жив, поэтому это как с электричеством: убивает ток, а не напряжение, потому что ток проходит через тебя. Накопленная радиация остается внутри организма и наносит постоянные повреждения.
Ошибка разработчиков и «Восставшая машина»? Ну-ну.
> хочется примкнуть к движению «дайте код посмотреть»
Уже обсуждали этот холивар, примерно год назад.
С одной стороны — ну ок, допустим все компании мира раскроют все свои коды(терабайты кодов) для всех. Вы сможете открыть код в блокнотике и почитать, чего же там Therac делает. Но хватит ли вам компетенции разобраться, какая должна подаваться мощность на выход, какие там стоят резисторы, работающие с этой энергией. Хватит ли вам компетенции знать, какие участки тела за что отвечают, как их нужно лечить и какой для всего этого должен быть код?
Продолжая эту тему, предположим, что вы нашли потенциальную ошибку в коде. Что вы будете делать? Напишете производителю. Производитель получает в день по 10 000 таких малосодержательных писем, с темой «у вас тут баг». А если даже тема будет содержательная, то производителю надо будет проверить — действительно ли там ошибка. Это время сотрудников, это деньги, это деньги которые обычная компания лучше направит на продажи, чем починку багов. Поэтому скорее всего, ваши письма будут просто игнорироваться.
Или допутсим вы получили исходный код чипа, который управляет вашим искуственным сердцем. Вы нашли «ошибку», решили перепрошить своё сердце, но хоп — ошибка в коде, чип отрубается, сердце останавливается. Или ты не правильно рассчитал формулу расчета нагрузки на сердца, и твоё сердцебиение вместо должных 90 ударов в минуту — вдруг начало выдавать 50? Стоит ли лезть, если ты нифига не понимаешь в этом? Что ты там увидишь в этом громадном коде?
Подводя итог — в воздухе витает наивное мнение, что если вдруг компании откроют исходный код, то сразу всем станет лучше, т.к. все вдруг ринутся этот код улучшать. В целом, так и происходит с обычным ПО, а что касается медицины, или полетов в космос — сомневаюсь в компетентности общества.
Уже обсуждали этот холивар, примерно год назад.
С одной стороны — ну ок, допустим все компании мира раскроют все свои коды(терабайты кодов) для всех. Вы сможете открыть код в блокнотике и почитать, чего же там Therac делает. Но хватит ли вам компетенции разобраться, какая должна подаваться мощность на выход, какие там стоят резисторы, работающие с этой энергией. Хватит ли вам компетенции знать, какие участки тела за что отвечают, как их нужно лечить и какой для всего этого должен быть код?
Продолжая эту тему, предположим, что вы нашли потенциальную ошибку в коде. Что вы будете делать? Напишете производителю. Производитель получает в день по 10 000 таких малосодержательных писем, с темой «у вас тут баг». А если даже тема будет содержательная, то производителю надо будет проверить — действительно ли там ошибка. Это время сотрудников, это деньги, это деньги которые обычная компания лучше направит на продажи, чем починку багов. Поэтому скорее всего, ваши письма будут просто игнорироваться.
Или допутсим вы получили исходный код чипа, который управляет вашим искуственным сердцем. Вы нашли «ошибку», решили перепрошить своё сердце, но хоп — ошибка в коде, чип отрубается, сердце останавливается. Или ты не правильно рассчитал формулу расчета нагрузки на сердца, и твоё сердцебиение вместо должных 90 ударов в минуту — вдруг начало выдавать 50? Стоит ли лезть, если ты нифига не понимаешь в этом? Что ты там увидишь в этом громадном коде?
Подводя итог — в воздухе витает наивное мнение, что если вдруг компании откроют исходный код, то сразу всем станет лучше, т.к. все вдруг ринутся этот код улучшать. В целом, так и происходит с обычным ПО, а что касается медицины, или полетов в космос — сомневаюсь в компетентности общества.
Иллюзия контроля — одно из когнитивных искажений, выражающееся в тенденции людей верить в то, что они каким-либо образом могут влиять на события, которые объективно от них не зависят или зависят в гораздо меньшей степени. Эффект проявляется, когда человек заинтересован в положительном исходе события и как-либо вовлечён в событие или ему заранее известен благоприятный исход.
> сомневаюсь в компетентности общества.
Зато компания-конкурент с радостью будет закапывать своих противников.
Опять же можно доверить проверку третьей стороне — как в случае трукрипта, где сообщество скидывается, чтобы нанять профессионалов.
Ну и некоторый код так пахнет, что его даже проверять не надо. Видишь код без единого комментария и теста, зато с процедурами по 500 строчек, и сразу понимаешь, что мимо этого куска говна лучше пройти.
Бизнес привык оптимизировать внешний вид приложений, чтобы ни один скриншот в обзорах не отпугнул пользователя. А если обзорщики начнут ещё и скриншоты кода публиковать, придётся вылизывать и его.
Зато компания-конкурент с радостью будет закапывать своих противников.
Опять же можно доверить проверку третьей стороне — как в случае трукрипта, где сообщество скидывается, чтобы нанять профессионалов.
Ну и некоторый код так пахнет, что его даже проверять не надо. Видишь код без единого комментария и теста, зато с процедурами по 500 строчек, и сразу понимаешь, что мимо этого куска говна лучше пройти.
Бизнес привык оптимизировать внешний вид приложений, чтобы ни один скриншот в обзорах не отпугнул пользователя. А если обзорщики начнут ещё и скриншоты кода публиковать, придётся вылизывать и его.
Насколько я помню, профессионалы не смогли дать 100% гарантию, что в трукрипте нет закладок. В основном они анализировали последние изменения в коде, а не весь код.
Но вот хакеры точно порадуются открытым исходникам. Я вот помню, как через полгода-год, как утекли исходники win2000, появилось множество весьма жестких руткитов.
Но вот хакеры точно порадуются открытым исходникам. Я вот помню, как через полгода-год, как утекли исходники win2000, появилось множество весьма жестких руткитов.
Ну значит народ начнёт больше платить за безопасность. Сейчас её вроде как не видно, вот денег и не выделяется. А проблема цветёт и пахнет.
Профессионалы не могут дать гарантию, что там нет хитроумных закладок. Но по крайней мере там нет http_send(keys, «fbi.gov»);. В открытом коде польза не лично каждому пользователю, что каждый может смотреть, что там написано. Польза в том, что энтузиаст может посмотреть, и таким образом общее количество посмотревших будет намного больше, а косяков намного меньше. Не «Нет», а «намного меньше».
Багтрекеры компаний завалены бесполезными репортами типа «вот то не это» от юзеров, обычно невоспроизводимыми у разработчика. Когда код открыт, то от спецов приходят полезные и чёткие багрепорты, исправлять которые намного проще.
Багтрекеры компаний завалены бесполезными репортами типа «вот то не это» от юзеров, обычно невоспроизводимыми у разработчика. Когда код открыт, то от спецов приходят полезные и чёткие багрепорты, исправлять которые намного проще.
Ждем развития ИИ до уровня Скайнет
Пришла мысль, что в прошлое «проще» отправить не качка 120кг, а парочку «багов».
Конец вечности Азимова?
Это точно. Определить какие именно баги были засланы среди сотен тысяч имеющихся будет трудно.
А сейчас FDA и ко понавводили столько требований, что поднять стартап на тему медицинского софта почти нереально. И стоит задуматься — хорошо или плохо, что тогда случился этот скандал, который привёл к ситуации, что в других странах медицинский софт более развит, чем в США.
Наверное, это самый показательный пример в истории, чего может стоить «говнокод» (в данном случае — чей-то выпендр с установкой boolean-переменной способом x = x +1). Случай Therac-25 подробно разобран в книге «Наука отладки» (М. Тэллес, Ю. Хсих), рекомендую.
Другой показательный случай, разбор которого ещё ожидает своей статьи на Хабре — это ошибка в коде системы марсоходов Spirit/Opportunity, из-за которых они едва не были потеряны. Можно не сомневаться, что в 2003-м году с дисциплиной разработки в NASA всё обстояло гораздо лучше, чем у создателей Therac-25 в 1985-м. И тем не менее, ни один из тестов не проверял, что случится, когда FLASH-память марсохода окажется заполненной собранными данными больше определённого уровня. Марсоход летел-летел, прилетел, начал делать фото, память заполнилась и система зависла.
Показательно, что ситуацию с марсоходами спасла аппаратная возможность через независимый контур перезапустить систему и загрузить обновление. А ситуацию с Therac-25, наоборот, погубил отказ от аппаратной защиты от переоблучения.
Другой показательный случай, разбор которого ещё ожидает своей статьи на Хабре — это ошибка в коде системы марсоходов Spirit/Opportunity, из-за которых они едва не были потеряны. Можно не сомневаться, что в 2003-м году с дисциплиной разработки в NASA всё обстояло гораздо лучше, чем у создателей Therac-25 в 1985-м. И тем не менее, ни один из тестов не проверял, что случится, когда FLASH-память марсохода окажется заполненной собранными данными больше определённого уровня. Марсоход летел-летел, прилетел, начал делать фото, память заполнилась и система зависла.
Показательно, что ситуацию с марсоходами спасла аппаратная возможность через независимый контур перезапустить систему и загрузить обновление. А ситуацию с Therac-25, наоборот, погубил отказ от аппаратной защиты от переоблучения.
Спасибо за статью, но с википедии откровенно абзацы копипастили. Странно, что гугл-транслейт переводит название устройства как: The rac — РАК…
В блоге PVS Studio как-то привыкли больше к разбору кода более конкретно. В связи с этим вопрос — а есть ли хоть какие-то открыто доступные куски кода, в которые можно ткнуть пальцем и показать «вот здесь ошибка, так как ...»?
многовато прямых заимствований с русскоязычной википедии, скажем прямо, копипаста.
статью без потери содержания можно было написать так:
«напоминаем, что в истории случился смертоносный программный баг в рентгеновской медицинской технике. пройдите по ссылке https://ru.wikipedia.org/wiki/Therac-25 », далее оставить два последних абзаца этой публикации (дополнительнительные ссылки и заключение)
статью без потери содержания можно было написать так:
«напоминаем, что в истории случился смертоносный программный баг в рентгеновской медицинской технике. пройдите по ссылке https://ru.wikipedia.org/wiki/Therac-25 », далее оставить два последних абзаца этой публикации (дополнительнительные ссылки и заключение)
UFO just landed and posted this here
Это по сути ускоритель электронов. Он мог жарить опухоль непосредственно пучком электронов, тогда мощность маленькая, плюс пучок мог специально быть несфокусированным. А мог с помощью торможения пучка электронов на металлической мишени генерировать рентген, которым жарилась опухоль. Вот только КПД этого процесса в районе 1%, если не ошибаюсь. Поэтому нужен начальный мощный пучок электронов. Баг в том, что включён типа режим рентгена, но металлической мишени на пути пучка нет, мощный пучок электронов сразу идёт в пациента.
«Он мог жарить опухоль непосредственно пучком электронов» не совсем так — пучок электронов, он же бэта-излучение, является пучком заряженных частиц, которые за счет наличия заряда очень хорошо поглощаются веществом, тогда как рентгеновское излучение — поток фотонов высокой энергии без заряда. Таким образом, нормально можно «жарить» потоком электронов только некрупную поверхностную опухоль.
Уточню.
Рентгеновское излучение жарит широким фронтом на всю глубину ткани, что может быть плохо.
Корпускулярная терапия (электронная, протонная и т.д.) позволяют регулировать глубину и толщину прожариваемого участка уменьшая побочные эффекты за счет того, что большую часть энергии частицы выделяют пиком в самом конце пробега.
По адресу https://en.wikipedia.org/wiki/Particle_therapy приведен график глубины проникновения. Из него хорошо видно, что при одной энергии электроны можно «сфокусировать» точно под поверхностью, а рентген пройдет куда глубже и будет повреждать не только цель.
Рентгеновское излучение жарит широким фронтом на всю глубину ткани, что может быть плохо.
Корпускулярная терапия (электронная, протонная и т.д.) позволяют регулировать глубину и толщину прожариваемого участка уменьшая побочные эффекты за счет того, что большую часть энергии частицы выделяют пиком в самом конце пробега.
По адресу https://en.wikipedia.org/wiki/Particle_therapy приведен график глубины проникновения. Из него хорошо видно, что при одной энергии электроны можно «сфокусировать» точно под поверхностью, а рентген пройдет куда глубже и будет повреждать не только цель.
В продолжение темы: "PVS-Studio — дополнительная страховка медицинского программного обеспечения".
Sign up to leave a comment.
Баг-убийца. Фигак, фигак и Therac-25