что такое баг бари
Смартфоны BlackBerry
По возрастанию цены
Недавно просмотренные
Доставка со страховкой
Посылки застрахованы от несчастных случаев
Поставка оригинального товара с 2007 года
Наши специалисты помогут в сложных вопросах
Авторизованный сервисный центр и полноценная гарантия
BlackBerry Russia – надежный поставщик товаров и услуг для бизнеса с 2007 года.
©2007 – 2021 BLACKBERRY RUSSIA
Работает в ОБЛАКЕ
Подпишитесь на нас
©2007 – 2021 BLACKBERRY RUSSIA
Работает в ОБЛАКЕ
Мельница мифов: откуда взялись буки и баги?
Весьма распространенным заблуждением считается история о том, что будто бы слово «баг» в значении «ошибка компьютерной программы» появилась в 40-х годах прошлого столетия после того, как бабочка, попав в механизм одного из первых компьютеров, вызвала сбой в его работе. Но это не так — данное слово в подобном значении использовалось еще в XIX веке.
Что означает слово «баг»?
Не знаю, как у вас, а лично у меня всегда возникал вопрос — какая ассоциативная связь между насекомым и программной ошибкой? Я задавал его многим моим друзьям, которые занимались программированием, и практически все они рассказывали мне такую историю. Оказывается, один раз насекомое действительно устроило сбой работы компьютера. Впрочем, давайте обо всем по порядку.
Давным давно, 9 сентября 1945 года ученых Гарвардского университета вызвали для того, чтобы определить причину сбоя в работе вычислительной машины Mark II Aiken Relay Calculator, который произошел накануне. Покопавшись в этой громадной куче приборов, соединенных проводами, они обнаружили бабочку, застрявшую между контактами электромеханического реле. Стало ясно, что именно она и явилась причиной сбоя. Одна из сотрудниц университета Грейс Хоппер так сформулировала результат исследований: «неполадку вызвал баг». После чего извлеченное насекомое было вклеено скотчем в технический дневник, с соответствующей сопроводительной надписью. Которую, по словам моих знакомых, до сих пор можно увидеть в этом журнале, хранящемся в университетском научном музее.
Я думаю, эту историю слышали многие и даже посчитали ее правдивой. Но на самом деле все было не совсем так, как описывается в канонической версии.
Из чего следует то, что о существовании «мерзкого жука», устраивающего помехи, техники и ученые знали и раньше, просто никак не могли его найти. Но тогда получается, что слово «баг» в значении «ошибка, сбой» появилось на свет не в 1947 году?
Баги во второй мировой войне
Действительно, это так. Если посмотреть документы, относящиеся к периоду Второй мировой войны, то вы найдете использование этого слова в соответствующем значении чуть ли не в каждом втором отчете американских и английских радистов. Тогда «багами» называли самые разные помехи, возникающие при радиосвязи
Так что фраза о том, что «связь установить не удалось из-за багов на данной частоте» была вполне обычной.
Кто первым употребил слово «баг» в нынешнем значении слова?
Однако, как выяснилось, на самом деле данный термин куда старше XX столетия. Его можно встретить, например, в дневниках Томаса Эдисона. Так, в 1878 году он писал о том, что:
«Это повторялось снова и снова со всеми моими изобретениями. Первым шагом была интуиция, за ней следовала вспышка, затем возникали препятствия — и они исчезали, потом возникали Баги — так называются маленькие недочеты и трудности — и необходимы месяцы постоянного поиска, исследований и тяжелого труда до успеха или неудачи».
А в 1889 году во многих газетах появились сообщения о трудностях, которые испытывал Эдисон, тестируя свой новый фонограф. По словам самого изобретателя, он: «не спал две ночи подряд, пытаясь обнаружить баг». Далее в тексте говорилось о том, что этим багом было постоянное шуршание, возникающее через некоторое время после включения прибора. Любопытно, что именно тогда данный термин впервые попал в Оксфордский словарь английского языка, причем в качестве примера употребления приводилась та самая выдержка из газетной статьи. А в 1943 году это значение слова «баг» было приведено в словаре Вебстера, и опять-таки со ссылкой на Эдисона.
Впрочем, вряд ли данный смысл в слово «баг» вложил сам изобретатель. Согласно другим свидетельствам, его в то время вовсю использовали служащие различных телеграфных компаний. Поэтому точно сказать, когда же оно было введено в оборот, и кто конкретно это сделал, увы, не представляется возможным. Впрочем, не исключено, что таковых «новаторов» было несколько.
Почему насекомое стало «багом» или помехой?
Но почему же в качестве термина, обозначающего помеху, было приведено именно слово, обозначающее насекомого? Какая связь между нашими шестиногими соседями и ошибками в работе оборудования? Может быть, они, подобно гарвардской бабочке, влезали в приборы и ломали их? Не исключено, что где-то так и было, но в таком случае этот термин не был бы впервые распространен телеграфистами — ведь работе их устройств никакие реальные жуки помешать не могут.
Есть также версия, что данное слово было использовано потому, что первыми багами были звуки, напоминающие скрип и шорох, какой легко могут производить насекомые. Однако вряд ли дело в этом —
могут не только они. За что же им выпала «особенная честь»? Скорее всего, реальные насекомые здесь вообще не причем.
Слово «баг» произошло от детского страшилища
Просто в староанглийском языке у слова «баг» было еще одно значение, которое сейчас мало кто помнит.
Этим словом обозначалась некая категория сверхъестественных существ (фэйри), которые, в отличие от милых фей и дружелюбных эльфов, не очень-то жаловала людей. А если быть совсем точными, детей. Согласно легендам, баг — «детское» страшилище, которым иногда даже в наше время англичанки и американки пугают своих непослушных отпрысков (не исключено, что русское народное страшилище «бука», которую время от времени призывают на помощь наши мамы и бабушки, является лингвистической сестрой этих монстров). Внешний облик багов может быть различным.
Несмотря на свой угрожающий облик, особого вреда они детям не приносят. Баги совсем не агрессивны, и, кроме того, у них нет ни острых зубов, ни длинных когтей. Они лишь могут напугать ребенка, — например, скорчив страшную уродливую рожу, растопырив лапы и подняв шерсть на загривке. Или устроив шум, писк и шорох в темном углу, мешая сорванцу заснуть. То есть можно с уверенностью сказать, что багам свойственно создавать помехи посредством шороха, скрипа и писка.
Судя по всему, и телеграфисты, и Эдисон, и многие другие, вводя в оборот новый термин, имели в виду именно этих сказочных багов. Поскольку все они когда-то были детьми и слышали про них от своих мам, бабушек и нянь. Так что, скорее всего, именно таким образом детская страшилка переквалифицировалась в электронную помеху. А позже — и в ошибку в программы…
Добавьте «Правду.Ру» в свои источники в Яндекс.Новости или News.Google, либо Яндекс.Дзен
Быстрые новости в Telegram-канале Правды.Ру. Не забудьте подписаться, чтоб быть в курсе событий.
Алибасов снова пристаёт к рабочему люду на улицах столицы
Продюсер группы «На-На» вышел в народ. Бари Алибасову, похоже, не сидится дома. Главный «нанаец» страны ищет себе друзей среди рабочего класса Москвы. Особенно влечёт шоумена к дорожным работникам и коммунальщикам.
После всех злоключений, которые происходили с продюсером, Бари Алибасов поправился. Звезда шоу-бизнеса активен как никогда. Почему-то знаменитость потянуло к простому народу. Алибасов ходит по улицам столицы и привлекает к себе внимание трудящихся.
В Instagram-аккаунте шоумена появилось видео, на котором он проник в центр женского коллектива уличных уборщиков. Женщины в дорожной униформе приняли Бари Каримовича в свои ряды с распростёртыми объятиями. Труженицы собрались вместе, чтобы сделать с лидером группы «На-На» памятный снимок.
Контент Алибасова в последнее время состоит именно из прогулок по Москве. Артист то даёт указания водителям спецтехники, то «впадает в детство» на игровых площадках столицы.
Подписчики «нанайца» оценили его взаимную любовь к трудовому народу
«Здорово. Вот смотрю видео, какие женщины счастливые. Такого человека встретили»;
«Гений ближе к народу»;
«Ух ты, Бари Каримович, в какой малине оказался»;
«Встреча с поклонниками удалась», — комментируют видео Алибасова в сети.
Добавьте «Правду.Ру» в свои источники в Яндекс.Новости или News.Google, либо Яндекс.Дзен
Быстрые новости в Telegram-канале Правды.Ру. Не забудьте подписаться, чтоб быть в курсе событий.
Что такое баги, ворнинги и исключения в программировании
Разбираемся, какие бывают типы ошибок в программировании и как с ними справляться.
Многим известно слово баг (англ. 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
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 никогда не играл и могу пересказать проишествие только с чужих слов. Возможно, кто-то из читателей меня поправит.
Суть бага. По задумке гейм-дизайнеров, эффект должен был действовать только в домашней локации Хаккара и никак не мог затронуть персонажей в других местах. Они не учли только один момент – зараженный игрок мог телепортироваться в другую локацию, заразив ничего не подозревающих соседей.