что означает слово баг

Значение слова «баг»

Термин «баг» обычно употребляется в отношении ошибок, проявляющих себя на стадии работы программы, в отличие, например, от ошибок проектирования или синтаксических ошибок. Отчет, содержащий информацию о баге также называют отчетом об ошибке или отчетом о проблеме (англ. bug report). Отчет о критической проблеме (англ. crash), вызывающей аварийное завершение программы, называют крэш-репортом (англ. crash report).

«Баги» локализуются и устраняются в процессе тестирования и отладки программы.

1. комп. жарг. ошибка в компьютерной программе ◆ В программе найден баг. ◆ Это не баг, это фича

2. комп. жарг. запись в багтрекере ◆ Пометил баг 419594 как WONTFIX. Если у кого есть какие-нибудь возражения/предложения, то рекомендую писать на странице обсуждения бага… «Форум Mozilla Россия», 2008 г.

Баг I

1. мужское имя ◆ Моего друга зовут Баг.

Делаем Карту слов лучше вместе

Привет! Меня зовут Лампобот, я компьютерная программа, которая помогает делать Карту слов. Я отлично умею считать, но пока плохо понимаю, как устроен ваш мир. Помоги мне разобраться!

Спасибо! Я обязательно научусь отличать широко распространённые слова от узкоспециальных.

Насколько понятно значение слова праветь (глагол), правей:

Источник

Типы багов: этимология и энтомология

1. Немного этимологии и энтомологии
Давайте посмотрим попристальней на такое знакомое и (до боли?) родное слово БАГ. Происходит оно от английского слова Bug, означающего «насекомое». Есть еще много сторонних значений, в частности английское выражение «to go bugs» — сойти с ума, что легко кореллируется со вполне русским «тараканы в голове завелись». Также вспоминаются и «жучки на линии» (тоже, кстати, по-английски – bugs). И опять мы пришли к насекомым.

Еще в 1878 году, Томас Альва Эдисон (да-да, тот самый!) в письмах к своему соратнику Пускасу писал: «It has been just so in all of my inventions. The first step is an intuition, and comes with a burst, then difficulties arise — this thing gives out and [it is] then that ‘Bugs’ — as such little faults and difficulties are called — show themselves and months of intense watching, study and labor are requisite before commercial success or failure is certainly reached». Тем же словом, инженеры называли и сбои радарной электроники во время второй Мировой Войны. Конечно, более распространена история о том, что в 1946 году разработка компьютера Марк-2 (Mark-II) были приостановлена из-за сбоя его функционирования, вызванного попаданием мотылька между контактов. Трупик мотылька был извлечен и приклеен к отчету липкой лентой с комментарием «First actual case of bug being found.» («Первый реальный случай нахождения жучка»). Как нетрудно догадаться, примерно оттуда же «растут уши» и слова «дебаггер» (debugger) – буквально «избавитель от жучков».

2. Виды багов.
Простейший (не как инфузория-туфелька, а самый простой для понимания, модно сказать «классический») баг – это несоответствие между ожидаемым результатом (ОР) и фактическим результатом (ФР). Разберем это на примере:

(это, кстати, реальный баг старого Microsoft Excel – он не учитывал приоритета математических операций, по которому умножение имеет высший приоритет по сравнению со сложением)

Все просто. Ждем одно – получаем другое. Баг.
Я не буду перечислять все подвиды бага классического – от опечаток в данных и опечаток в коде до бесконечных циклов, от использования оператора присвоения вместо оператора проверки равенства до использования неинициализированной переменной, от состояния гонки (race condition) в мультипоточных приложения до переполнения буфера, и так далее, и тому подобное – все это достаточно обыденные и ясные явления. Обратимся к малознакомой экзотике.

2.1. Гейзенбаг (Heisenbug)
Баг, названный в честь Гейзенбергского Принципа неопределенности – концепции квантовой физики. Простым (хоть слово «просто» здесь и не очень применимо) примером подобного бага будет являться ошибка, проявляющаяся, когда программа запускается на исполнение в рабочей среде, но исчезающая, когда программу запускают в дебаггере.

2.2. Борбаг (Bohrbug)
Тип бага, названный так в честь атомной модели Бора. В противоположность Гейзенбагу, он проявляется постоянно при одном и том же стечении обстоятельств. Вопрос в том, что весь набор обстоятельств бывет невозможно (или очень трудно) отследить.

2.3. Мандельбаг (Mandelbug)
Назван в честь Бенуа Мандельброта, внесшего огромный вклад в теорию фракталов. Мандельбагами называют ошибки, чьи причины настолько сложны и неясны, что фактически кажутся хаотичными и не поддающимися описаниями. (ключевое слово «кажутся»). Подобное, может быть вызвано, например, медленной реакцией системы – то есть ошибка уже произошла, но об этом вы узнаете только через некоторое время, что сильно затруднит локализацию причин.

2.4. Шрединбаг (Schroedinbug)
Шрединбаг назван в честь известного парадокса с кошкой Шредингера (или эта несчастная животина – кот?). Он заключается в том, что кто-нибудь читает код программы (работающей уже некоторое время) и восклицает «Да этого не может быть! Она просто не может функционировать!», после чего программа прекращает свое функционирование пока данная ошибка не будет исправлена. Будучи, казалось бы, абсолютно фантастической, данная ошибка попадается в реальности – спросите знакомых ветеранов- разработчиков, они подтвердят. Хотя, конечно, последующий анализ, как правило, позволяет отнести ошибку к разделам 2.1, 2.2 или 2.3, это удается не всегда.

2.5. Фазы луны
На самом деле такой ошибки не существует – это популярная отговорка тех, кто не хочет (не имеет желания и/или времени) разбираться в сложных причинах возникновения ошибки. Тем не менее, в истории существует пара примеров, когда ошибки возникали буквально из-за фаз луны. Я не буду приводить здесь эти истории, надеясь, что никому из нас не придется работать со столь сложными устройствами. Тем не менее, в любом случае, хотелось бы предостеречь всех от неосторожных умозаключений и попросить быть более внимательными, настойчивыми и скрупулезными в своей работе.

2.6. Статистический (более известный как количественный) баг
Баг возникающий при произведении программой большого количества каких-либо действий. Примером данной ошибки может служить запуск программы, которая должна равномерно расположить на плоскости некоторое количество точек. Если, например, при большом количестве точек программа не только неправильно располагает их, но и норовит расположить все на одной стороне плоскости (при этом до определенного количества точек работая прекрасно) – вуаля, количественный баг.

2.7. Демонстрационный эффект.
Ну и конечно, известный всем, «эффект первого показа», не раз случавшийся и с вашим покорным слугой. Как только приходит пора показать, например, прекрасно функционировавший на тестовом стенде юнит, обязательно происходит что-то ужасное. Причны, как правило, тривиальны – пропуск «незначительных» тест-кейсов, невнимательность к деталям и неучтенные юз-кейсы. Опять же – будьте внимательней.

На этом я закончу краткий обзор багов, буду рад Вашим замечаниям и предложениям.

Источник

Что такое «компьютерная баг» и откуда взялся этот термин

В ы, наверное, слышали это раньше: в программном обеспечении есть «баг», из-за которого что-то работает неправильно. Что такое компьютерный баг и откуда появился этот термин? Мы объясним.

Баг- это непреднамеренная ошибка в компьютерном программном обеспечении

«Компьютерный баг» или «программный баг» — это термин, обозначающий непреднамеренную ошибку программирования или дефект в компьютерном программном обеспечении или оборудовании. Баги возникают из-за человеческой ошибки в конструкции оборудования или где-то в цепочке программных инструментов, используемых для создания компьютерных приложений, прошивок или операционных систем.

Программная ошибка возникает, когда программист либо делает ошибку при написании программного обеспечения, либо пишет код, который работает, но имеет непреднамеренные последствия, которые не были предвидены программистом. Устранение ошибок в программном обеспечении называется «дебаг».

В сегодняшнем мире ошибки в программном обеспечении — серьезное дело. Почти 20 лет назад Национальный институт стандартов и технологий подсчитал, что ошибки в программном обеспечении обходятся экономике США почти в 60 миллиардов долларов в год (около 0,6% ВВП в 2002 году), и с тех пор эта цифра, вероятно, увеличилась. Хотя точно количественно оценить негативные последствия ошибок сложно, легко представить, как неисправное программное обеспечение может повлиять на производительность. Это может даже подвергнуть опасности жизнь людей на транспорте или поставить под угрозу жизненно важную инфраструктуру, такую как электростанции.

Почему мы называем их багами

Термин «баг» появился еще до изобретения компьютеров, и мы точно не знаем, кто изначально придумал термин «баг» для обозначения инженерного дефекта. В письменных источниках историки проследили это до Томаса Эдисона не ранее 1870-х годов.

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

«Вы были частично правы, я действительно обнаружил «баг» в своем аппарате, но не в самом телефоне. Он принадлежал к роду callbellum. Похоже, насекомое находит условия для своего существования во всех телефонных аппаратах».

Хотя некоторые считают, что примеры Эдисона означают, что он ввел термин «баг», но вполне возможно, что он произошел от кого-то еще раньше и что он просто популяризировал этот термин среди своих друзей и соратников-инженеров. Оксфордский словарь английского языка цитирует пример 1889 года, связанный с Эдисоном, который описывает ошибку как метафору насекомого, заползающего в элемент оборудования и вызывающего его неисправность, предполагая, что настоящая ошибка, делающая именно это, могло первоначально послужить источником этого термина, похожего на термин «ложка дегтя».

Отбросив на мгновение слово «баг», первым известным человеком в истории, который осознал, что программное обеспечение может работать неправильно из-за ошибок в программировании, была Ада Лавлейс. Она писала об этой проблеме еще в 1843 году в своем комментарии к аналитической машине Чарльза Бэббиджа.

«На это можно ответить, что процесс анализа в равной степени должен быть выполнен для того, чтобы снабдить аналитическую машину необходимыми оперативными данными; и в этом также может заключаться возможный источник ошибки. При условии, что реальный механизм безошибочен в своих процессах, карты могут отдавать ему неправильные приказы».

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

Бабочка Грейс Хоппер

На протяжении десятилетий книги, журналы и веб-сайты ошибочно сообщали, что термин «баг» был придуман легендарным компьютерным ученым Грейс Хоппер, когда моль влетела в реле компьютера Harvard Mark II и вызвала его неисправность. Как гласит история, она затем записала мотылька в журнал и сделала историческую заметку: «Первый реальный случай обнаружения бага».

Хотя в 1947 году в Mark II действительно залетела моль, она не была источником терминов «баг» или «дебаг», которые предшествовали инциденту. Кроме того, не совсем ясно, действительно ли моль привела к неисправности компьютера, или это была просто забавная находка, пока они исправляли другие дефекты. Хоппер сделала эту историю известной, рассказав ее в широко цитируемом интервью от ноября 1968 года.

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

Интересно отметить, что Хоппер описывает мотылька Mark IV как «забитого до смерти», вероятно, из-за повреждений, вызванных движением электромеханических реле компьютера, что позволяет предположить, что компьютер продолжал функционировать, пока моль была там.

Историки не знают, был ли это дневник Хоппер или кто на самом деле написал запись, но сегодня журнал Harvard Mark II находится в Национальном музее американской истории в Смитсоновском институте в Вашингтоне, округ Колумбия.

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

Источник

Что такое баги, ворнинги и исключения в программировании

Разбираемся, какие бывают типы ошибок в программировании и как с ними справляться.

Многим известно слово баг (англ. bug — жук), которым называют ошибки в программах. Однако баг — это не совсем ошибка, а скорее неожиданный результат работы. Также есть и другие термины: ворнинг, исключение, утечка.

В этой статье мы на примере C++ разберём, что же значат все эти слова и как эти проблемы влияют на эффективность программы.

Пишет о программировании, в свободное время создает игры. Мечтает открыть свою студию и выпускать ламповые RPG.

Ошибки в программировании

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

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

Также существуют ворнинги (англ. warning — предупреждение). Они не являются ошибками, поэтому программа всё равно будет собрана. Вот пример:

Предупреждения не являются чем-то критичным, но могут иметь негативные последствия. Например, ваша программа будет использовать больше памяти, чем должна. Так как C++ нужен в том числе и для разработки высоконагруженных систем, этого допускать нельзя.

После восклицательного знака в треугольнике — количество предупреждений

Третий вид ошибок — ошибки сегментации (англ. segmentation fault, сокр. segfault, жарг. сегфолт). Они возникают, если программа пытается записать что-то в ячейку, недоступную для записи. Например:

Вот результат работы такого кода:

Баги в программах

Мы выяснили, что баг — это не совсем ошибка, а скорее неожиданное поведение программы или результат такого поведения. Баги могут быть чем-то забавным или неприятным. Например, как в играх:

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

Если ваш код приводит в действие какое-нибудь потенциально опасное устройство, то ценой такой ошибки может быть чья-нибудь жизнь. Такое случилось с кодом для аппарата лучевой терапии Therac-25 — как минимум два человека умерло и ещё больше пострадали из-за превышения дозы радиации.

Исключения в программах

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

Конвертировать введённое значение не всегда возможно, поэтому функция, которая занимается преобразованием, «выбрасывает» исключение (англ. exception). Это специальное сообщение говорит о том, что что-то идёт не так.

Если разработчик не описывает логику работы программы при вы выбрасывании исключения, то программа аварийно закрывается. Подробнее мы рассказали об этом в статье про ввод и конвертацию в C++.

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

Компилятор C++ при этом может выдать ошибку сегментации, а не сообщение о переполнении стека:

Вот аналогичный код на языке C#:

Однако сообщение в этот раз более конкретное:

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

Похожая ситуация — переполнение буфера (англ. buffer overflow). Она происходит, когда записываемое значение больше выделенной области в памяти.

Обратите внимание, что мы получили предупреждение об арифметическом переполнении (англ. integer overflow):

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

Арифметическое переполнение стало причиной одной из самых дорогих аварий, произошедших из-за ошибки в коде. В 1996 году ракета-носитель «Ариан-5» взорвалась на 40-й секунде полёта — потери оценивают в 360–500 миллионов долларов.

Как избежать всех этих ошибок

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

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

Второй, более эффективный метод — unit-тесты. Они представляют из себя набор описанных ситуаций для каждого компонента программы с указанием ожидаемого поведения.

Например, у вас есть функция sum (int a, int b), которая возвращает сумму двух чисел. Вы можете написать unit-тесты, чтобы проверять следующие ситуации:

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

Заключение

Ошибок существует слишком много. При этом самые опасные тяжелее обнаружить, что только усугубляет ситуацию.

Если вы хотите научиться писать качественный код и находить в нём ошибки, вы можете записаться на наш курс по разработке на C++.

Источник

masterok

Мастерок.жж.рф

Хочу все знать /наука, история, политика, творчество/

Мы как то обсуждали Политический код ошибки HTTP, а теперь перейдем к банальным БАГам.

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

Первое применение слова bug по отношению к технике приписывают Томасу Эдисону. По одной из легенд, еще во время работы над фонографом, он долго не мог понять, почему же собранный прототип отказывается работать. Перебрав в уме все возможные варианты и так и не найдя решения, он предположил, что во время сборки между деталями устройства мог попасть жук. И хотя на самом деле никаких насекомых в фонографе не оказалось, в будущем он продолжил использовать слово bug для обозначения досадных неисправностей.

В качестве примера можно привести одну из записей из его рабочего дневника, датированную 1878 годом:

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

Любопытно, что слово debugging, которое в наши одни обозначает этап отладки программы и поиск всех возможных проблем, встречалось еще в Оксфордском словаре 1945 года выпуска. Правда, тогда речь шла не о программах, а об авиационных двигателях.

Применимо к компьютерам и программному обеспечению слова «баг» и «дебагинг» стали использовать несколько позже. Считается, что родоначальником этой традиции в 1946 году стала контр-адмирал флота США Грейс Хоппер, которая столкнулась с неполадкой в работе с вычислительной машиной Harvard Mark II. Как выяснилось впоследствии, причиной странного поведения ЭВМ оказался самый обычный мотылек, который попал между контактами одного из электромеханических реле. Трупик несчастного насекомого был бережно извлечен из недр машины и приклеен скотчем к странице рабочего дневника. Подпись ниже гласила: «Первый реальный случай обнаружения бага».

В наш с вами век реальные насекомые уже вряд ли смогут привести к сбою в работе программы. Зато вот их цифровые сородичи ежегодно доставляют людям кучу проблем. Случаев, когда одна крохотная ошибка программиста приводила к огромным неприятностям, в новейшей истории полно и случай в iPhone – еще цветочки.

Временные сложности

Сломать за 60 секунд

На днях владельцы техники Apple случайно выяснили, что если установить на iPhone или iPad дату 1 января 1970 года, а затем перезагрузить устройство, то оно превратится в «кирпич». На экране будет вечно светиться логотип Apple и больше загрузиться устройство не сможет уже никогда. Ну или как минимум – до вашего визита в сервисный центр, хотя и с этим пунктом пока не все ясно.

На данный момент установлено, что ошибка встречается на мобильных устройствах Apple с 64-битными процессорами Apple A7, A8, A8X, A9 и A9X. Версия ОС значения не имеет. Категорически не рекомендую проводить подобные эксперименты на своем аппарате – это гарантированно приведет к серьезной поломке, справиться с которой своими силами вы не сможете. Так же хочу обратить ваше внимание на всевозможные «приколы», уже второй день гуляющие по интернету. Шутники предлагают поменять время на смартфоне чтобы увидеть секретную пасхалку или суметь бесплатно скачать платные программы из AppStore. Результат – «кирпич» вместо смартфона.

Суть бага. В Unix-подобных ОС время считается не совсем привычным для нас образом. Для Unix текущее время – это число секунд, прошедшее от точки отсчета, за которую была принята полночь 1 января 1970 года. Для человека такой способ не очень удобен, а вот для компьютера — в самый раз. Что именно происходит в «голове» у iPhone, который решил, что присутствует при зарождении Unix вселенной, пока не известно, но что сказывается это на нем не лучшим образом – уже неоднократно проверенный факт.

Впрочем, попытаться самим предположить, где именно закрался «баг», нам никто не мешает.

Те, кто играл в игры времен MS-DOS наверняка сталкивались с разными багами, возникающими при переполнении счетчика. К примеру, в Civilization был очень миролюбивый правитель по имени Ганди, у которого параметр агрессии был равен 1. Если его еще немного «задобрить», предложив принять какой-то подарок или заключив союз, значение агрессии вначале падало до нуля… а затем резко взлетало до небес. Дело в том, что переменная предполагала значения от 0 до от 255 и при попытке отнять единицу от нуля вновь становилась максимальной. Программисты просто не предусмотрели проверку текущего значения переменной, что и приводило к ошибке.

Подобная ситуация встречалась и во многих других играх. К примеру, в оригинальной X-Com максимально прокачанный боец рисковал внезапно стать беспомощным младенцем, так как с очередной прибавкой к характеристикам значения счетчиков скидывались до нуля.

Можно предположить, что что-то подобное происходит и с iPhone — во время загрузки iOS для каких-то своих целей требуется взять значение времени, которое на пару секунд меньше текущего… а так как дата 1 января 1970 года и так принята системой за 0, то в результате значение 64-битной переменной становится максимальным. Ради интереса можно попробовать посчитать, какая это получается дата, но очень подозреваю, что наше Солнце к тому времени уже точно погаснет.

Уверен, что рано или поздно с этой проблемой Apple разберется. Но вот 19 января 2038 года я бы все же посоветовал всем быть поосторожнее – именно в этот момент значение Unix-времени превысит 2147483647 и перестанет помещаться в стандартную переменную (беззнаковое 32-битное целое число). И как на это отреагируют 32-битные устройства по всему миру — загадка.

Баг Тысячелетия

Суть бага. Во многих ОС год записывался только двумя последними цифрами. Так, для обозначения 1998 года использовались цифры 98, для 1999 – 99 и так далее. По этой системе 2000 год обозначался как 00, что для компьютера ничем не отличалось от 1900 года.

Несмотря на свое страшное название, на практике ни к каким особым проблемам этот баг не привел. Может быть, за это стоит благодарить оперативно сработавших программистов, которые к 2000 году смогли исправить большую часть ПО. А возможно, что это просто у страха глаза были велики. В любом случае, по-настоящему опасные баги выглядят совершенно иначе и крайне редко предупреждают о своем существовании за несколько лет до возникновения потенциальной проблемы.

Через тернии к звездам

Самый дорого дефис в истории

Маринер-1 – космический аппарат NASA, который был создан для изучения Венеры. Запуск аппарата состоялся 22 июля 1962 года, однако уже через несколько минут после старта он был уничтожен.

Первые проблемы начались уже спустя 293 секунды после запуска, именно в этот момент Маринер-1 потерял связь с Землей. Такая ситуация была изначально предусмотрена инженерами, и управление аппаратом принял на себя бортовой компьютер. Вот только компьютер тут же «запаниковал» и выдал команду на очень сильную коррекцию курса, которая в тот момент была совершенно не нужна и вывела Маринер-1 на опасную траекторию. Так как падение ракеты к тому моменту было уже практически неминуемо, специалисты NASA приняли решение ее уничтожить.

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

Впрочем, в некоторых версиях произошедшего вместо символа надчеркивания фигурирует дефис, а кто-то предполагает, что во время составления программы на Фортране программист просто перепутал точку с запятой.

Метод копипаста

«Ариан 5» (фр. Ariane 5) — европейская ракета-носитель семейства Ариан, предназначена для выведения полезной нагрузки на низкую опорную или геопереходную орбиту. Она до сих пор является основной ракетой-носителем ЕКА и останется таковой минимум до 2023 года. И тем не менее, ее первый запуск закончился аварией, которая стала примером одного из самых дорогих багов в истории.

Суть бага. Во время работы над ПО новой ракеты программисты использовали куски уже готового кода, ранее написанного ими для Ариан 4. В результате, иные технические характеристики новой ракеты и немного другая расчетная траектория полета привели к тому, что ее текущая скорость превысила имеющиеся в программе ограничения. В какой-то момент бортовой компьютер просто не смог перевести значение скорости из 64-битного формата в 16-битный (число оказалось больше 32,767 и просто «не влезло» в переменную), что и вызвало сбой в работе ПО.

Цена ошибки

Защита от дурака

В сентябре 1997 года авианосец США USS Yorktown в течение трех часов дрейфовал в море с неработоспособными бортовыми компьютерами и системой управления ходовой частью. К счастью для экипажа, ситуация произошла во время учебных маневров, а не боевых действий.

Суть бага. На ноль делить нельзя – это знают даже ученики начальной школы. Но компьютер – не человек, и, если попросить его поделить какое-то число на ноль, он честно попытается это сделать. Причем, этой неразрешимой задаче он станет уделять все свое время и внимание. Если, конечно, программист не предусмотрит специальную «защиту от дурака», которой в бортовых системах USS Yorktown почему-то не было. В результате, когда один из членов экипажа по ошибке ввел ноль в бортовую систему управления, она вышла из строя, на несколько часов оставив авианосец совершенно беспомощным.

Одна треть секунды

К сожалению, далеко не все «баги» в ПО оканчиваются столь удачно. Очень часто они могут привести к человеческим жертвам, что и произошло в 1991 году во время войны в Персидском заливе. Из-за ошибки в ПО зенитный ракетный комплекс Patriot отказался перехватывать запущенную ракету, что привело к человеческим жертвам.

Суть бага. Из-за особенностей округления времени, каждые 100 часов бесперебойной работы ЗРК Patriot его часы сбивались примерно на треть секунды. В итоге компьютер вовремя обнаружил запуск вражеской ракеты, но из-за бага со временем допустил критическую ошибку при просчете траектории. Решив, что ракеты уже не существует, система отменила попытку перехвата.

Цепная реакция

Компьютерный разум

Чёрный понедельник (англ. Black Monday) — понедельник 19 октября 1987 года — день, в который произошло самое большое падение индекса Доу-Джонса за всю его историю. Хотя еще утром абсолютно ничто не предвещало беды и никаких объективных причин для обвала рынка просто-напросто не было.

Суть бага. До сих пор есть несколько теорий произошедшего, но в большинстве случаев основной причиной называют примитивную логику ПО для программного трейдинга. В какой-то момент рынок начал падать, и самые осторожные «электронные помощники» трейдеров поспешили побыстрее избавиться от всех дешевеющих ценных бумаг. Это привело к тому, что вместо обычной коррекции случилась самая настоящая цепная реакция — рынок оказался перенасыщен, цены на бумаги упали еще больше и в дело включилось ПО остальных игроков. В итоге один крохотный снежок спровоцировал огромную горную лавину, которую никто совершенно не ожидал.

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

Эпидемия

Спустя несколько часов в мире игры разразилась страшная эпидемия, которая выкашивала целые города. Улицы были завалены трупами персонажей игроков, а выжившие в страхе шарахались от любой тени, боясь подцепить смертельную заразу. Как-то совладать с ситуацией удалось только после перезапуска игровых серверов, во время которого программисты в спешном порядке установили специальный патч, исправляющий ошибку. И думаю, что тот день многие игроки запомнили надолго.

Впрочем, сам я в World Of Warcraft никогда не играл и могу пересказать проишествие только с чужих слов. Возможно, кто-то из читателей меня поправит.

Суть бага. По задумке гейм-дизайнеров, эффект должен был действовать только в домашней локации Хаккара и никак не мог затронуть персонажей в других местах. Они не учли только один момент – зараженный игрок мог телепортироваться в другую локацию, заразив ничего не подозревающих соседей.

Источник