Луна убывает, такое бывает… ©Земфира
Гейзенбагом называют ту разновидность программных глюков, которая возникает не пойми откуда, не поддается отладке и обнаружению. Словом, ведет себя как тот самый Неуловимый Джо или кроковский кот из недавнего поста. Мне по работе приходилось сталкиваться с такими и про себя я называл это эффектом квантовой механики до тех пор, пока не узнал, что близкое по смыслу название уже давно придумали. Бывает, посылаешь заказчику отладочный бинарник, который всего лишь записывает в журнал больше событий вокруг предполагаемого источника проблемы и после этого проблема исчезает!
heisenbug /hi:'zen-buhg/ n.
A bug that disappears or alters its behavior when one attempts to probe or isolate it.
Предлагаю вашему вниманию свою небольшую познавательную коллекцию квантовых эффектов в программировании.
Эпизод I, OpenOffice не печатает во вторник
Историю этого замечательного багрепорта можно почитать на Ubuntu Launchpad, а я вкратце изложу суть для тех, кому не сподручно читать по ссылке. В системной утилите file был баг из-за которого, файлы содержащие в 4-м байте Tue определялись как Erlang JAM. Дефект присутствовал в версиях file 4.21 и 4.24 и был вызван ошибкой в magic файле.
anon@x-X:~$ echo "1/2 Tue" >> file && file file
file: Jan 22 14:32:44 MET 1991\011Erlang JAM file - version 4.2
anon@x-X:~$ file --version
file-4.21
magic file from /etc/magic:/usr/share/file/magicЭто приводило к тому, что по вторникам для бажной версии file временные отметки PostScript файлов были похожи на Erlang JAM.
%%CreationDate: (Tue Mar 3 19:47:42 2009)При отправке задания на принтеры семейства Brother, OpenOffice запускал процедуру проверки PostScript файла, которая завершалась ошибкой, потому что обнаруживала тип файла Erlang JAM. Исправление, в основном, свелось к экранированию пробела.
+# 4.2 version may have a copyright notice!
-+4 string Tue Jan 22 14:32:44 MET 1991 Erlang JAM file - version 4.2
-+79 string Tue Jan 22 14:32:44 MET 1991 Erlang JAM file - version 4.2
++4 string Tue\ Jan\ 22\ 14:32:44\ MET\ 1991 Erlang JAM file - version 4.2
++79 string Tue\ Jan\ 22\ 14:32:44\ MET\ 1991 Erlang JAM file - version 4.2Впрочем, и с бажным file проблема устранялась просто, однако к тому моменту гейзенбагу уже исполнилось 9 месяцев!
sed -e '/^%%CreationDate:/s/Tue/tue/' > $INPUT_TEMPЭпизод II, Луна и Perl
Однажды на просторах сети мне попался этот прекрасный экземпляр ИТ юмора. Изнывая от скуки, разработчик Debian решил вычислить зависимость багрепортов от фазы Луны и быстренько написал такой скриптец.
#!/usr/bin/perl -w
use strict;
use warnings;
use constant PI => 3.1415926535;
use feature "say";
use SOAP::Lite;
use Astro::Coord::ECI::Moon;
my $soap = SOAP::Lite->uri('Debbugs/SOAP')->proxy('http://bugs.debian.org/cgi-bin/soap.cgi');
if (!defined($ARGV[0])) {
die "E: must have a source package!\n";
}
my @bugs = $soap->get_bugs(src=>$ARGV[0])->result();
my $bugsdata = $soap->get_status(@bugs)->result();
my $moon = Astro::Coord::ECI::Moon->new();
my %count = ( 'new' => 0, 'first' => 0, 'full' => 0, 'last' => 0);
foreach my $bug (keys %$bugsdata) {
my $time = $$bugsdata{$bug}->{date};
my $phase = $moon->phase($time);
if ($phase <= 45 * PI / 180 || $phase > 315 * PI / 180) {
$count{'new'} = $count{'new'} + 1;
} elsif ($phase <= 135 * PI / 180 && $phase > 45 * PI / 180) {
$count{'first'} = $count{'first'} + 1;
} elsif ($phase <= 225 * PI / 180 && $phase > 135 * PI / 180) {
$count{'full'} = $count{'full'} + 1;
} elsif ($phase <= 315 * PI / 180 && $phase > 225 * PI / 180) {
$count{'last'} = $count{'last'} + 1;
}
}
say "Number of bug submissions during new moon : " . $count{new};
say "Number of bug submissions during first quarter: " . $count{first};
say "Number of bug submissions during full moon : " . $count{full};
say "Number of bug submissions during last quarter : " . $count{last};Результат для пакета nbd был обнадеживающим, зависимость явно проклевывалась.
wouter@carillon:~code/perl$ ./debbugsmoon nbd
Number of bug submissions during new moon : 2
Number of bug submissions during first quarter: 10
Number of bug submissions during full moon : 1
Number of bug submissions during last quarter : 3Для наукообразности можно даже в R проверить гипотезу функциональной зависимости. Данных маловато, но цифры внушают — p-value = 0.005853.
> chisq.test(c(2, 10, 1, 3));
Chi-squared test for given probabilities
data: c(2, 10, 1, 3)
X-squared = 12.5, df = 3, p-value = 0.005853
Предупреждение:
В chisq.test(c(2, 10, 1, 3)) :
аппроксимация на основе хи-квадрат может быть неправильнойЯ решил повторить эксперимент спустя 6 лет, и что бы вы думали?
[5153:23311 0:604] 06:09:39 Вс авг 28 [mikayel@redeye: +4] ~
(4:604)$ ./debbugsmoon.pl nbd
Number of bug submissions during new moon : 1
Number of bug submissions during first quarter: 12
Number of bug submissions during full moon : 3
Number of bug submissions during last quarter : 1С этим nbd что-то явно не так, лунные фазы теперь давят сильнее!
> chisq.test(c(1, 12, 3, 1))
Chi-squared test for given probabilities
data: c(1, 12, 3, 1)
X-squared = 19.471, df = 3, p-value = 0.0002185
Предупреждение:
В chisq.test(c(1, 12, 3, 1)) :
аппроксимация на основе хи-квадрат может быть неправильнойВозможно, найдутся примеры и поярче, если проверить все 43 тысячи пакетов Debian Linux, но думаю это будет не лучшей тратой времени.
Эпизод III, Луна и LISP
Плохому танцору не всегда удаются сложные па, а программистам изредка гадит Луна. Нам об этом известно, благодаря хакерам старой школ, издавшем в 1983-м г. Словарь Хакера, у которого есть и другое название — the Jargon File. С тех пор книга выдержала еще несколько изданий и стала своего рода классикой жанра. В статье Phase of the Moon [1] есть довольно занятная байка на тему.
Однажды, Guy Steele [2], в то время еще студент MIT, словил баг в коде MacLisp [3], записывающей временные метки в отдельный файл содержащий формы, включив туда стандартную функцию приближенного вычисления фазы Луны. По неподтвержденным данным бажную программу также писал Gerry Sussman [4]. Изредка программа сбоила, причем случалось это каждый месяц в одно и то же время из-за того, что первая запись выкатывалась на новую строку, не обозначая комментарий символом ";". Длина первой записи зависела от временной метки и определенной фазы, то есть превышала широту страницы в 80 символов в зависимости от лунного календаря!
В той же статье упоминается еще один случай, когда в ЦЕРН сбоила программа обсчета результата экспериментов на ускорителе LEP коллайдера [5]. Долгие поиски причин сбоев наконец-то привели к разгадке. Кольцо периметра LEP, в 27 км. длиной, было очень незначительно деформировано из-за гравитации Луны. Эта история стала частью фольклора в среде физиков, получив название Ньютоново Возмездие. За достоверность деталей этой истории не могу поручиться, так как т. н. приливные деформации известны уже десятки лет как. Хотелось бы узнать мнение Хабра на этот счет.
Эпизод IV, мой Гейзенбаг
Был у меня на старом ноуте совершенно безумный баг, который приводил к полному или частичному зависанию ОС в время прослушивания музыки через USB наушники, причем чаще всего к зависанию приводило прослушивание интернет-радио. Я это терпел пару-тройку лет а затем, поняв, что ничего не меняется от смены версий ядра Linux, Xorg и драйверов, отправил багрепорт в Gentoo Bugzilla.
This happens for already 4 years with kernels starting 2.6.20 to 2.6.31. Similarly it happened on «HP nc 6220» based no intel chipset running «Debian Linux 5.x.» again USB headphones were Plantronics DSP 300.
Surprisingly it never happens under liveCD, I tested few times keeping audio-streaming for 1 hour and nothing crashed.
В вольном переводе, это жалоба на то, что гейзенбагу уже 4 года и он одинаково хорошо себя чувствует на версиях Linux ядра с 2.6.20 по 2.6.31, на чипсете AMD Radeon Xpress 200M и интеловском 915GM, но почему-то не прижился на LiveCD дистрибутивах.
В момент зависания нигде сообщения об ошибке не возникало и только в /var/log/messages появлялась запись: N URBs still active, где N — четное число < 10. Скорее всего падеж происходил в модуля ядра snd_usb_audio, небрежно обрабатывался и приводил систему в ступор.
Последняя запись в багрепорте, что я поменял опции аппаратного ускорения для открытого графического драйвера radeon
Option "AccelMethod" "EXA" #было
Option "AccelMethod" "XAA" #сталопосле чего проблема испарилась, но непонятно как и зачем, ведь это изменение никаким образом не связано с snd_usb_audio.
- ^ Автор так обозначил разновидность Гейзенбага. По ссылке, the Jargon File, версия 4.3.3.
- ^ Автор книги Common Lisp the Language, один из создателей языка програмимрования Scheme.
- ^ Диалект языка программирования Lisp, разработанный в лаборатории искусственного интеллекта MIT.
- ^ Один из создателей языка программирования Scheme, со-автор книги Structure and Interpretation of Computer Programs.
- ^ Большой электрон-позитронный коллайдер.
Комментарии (82)
zooks
30.08.2016 18:30+6Напомню, что неуловимый Джо «никому не нужен».
temujin
30.08.2016 18:33+2Как поговаривают, любая аналогия хромает, в этом сравнении главное — внезапность и неуловимость.
MichaelBorisov
30.08.2016 23:01+1К сожалению, некоторые баги, проявляющиеся часто и тем самым критически влияющие на характеристики продукта, тоже могут попасть в категорию «гейзенбаг». Например, мне приходилось ловить баги, связанные с перепахиванием памяти в C++. То еще удовольствие. Программа, скомпилированная в режиме «Debug», работает, а в «Release» — не работает, но в Release ее нельзя препарировать отладчиком. Попытки же вставить в программу отладочную печать тоже приводят к невоспроизводимости сбоя: память перепахивается в другом месте. Ловля каждого такого бага — это уникальный опыт.
Jef239
31.08.2016 00:43Для тех, кто использует систему debug/release ловля бага — это удача. Сродни езде без рук и тормозов на одноколесном велосипеде. А если эту систему не использовать, то ловля багов — это технология. Основа закладывается на этапе написания кода:
— assert
— система логгирования
— try..except..finally
ну и сам собой — никакого деления на release/debug. Тяжелые проверки включаются динамически из конфига на том же коде.
Ну и технологии ловли на каждый тип бага. Например, перепахивание памяти ловится через аппаратные breakpoint на запись в данную память. В идеале — их можно настроить на логгирование, потом убрать дубликаты из списка адресов и посмотреть, откуда писали.
LifeKILLED
30.08.2016 18:49-3Код Шреденгера
Aremys
31.08.2016 14:09уважаемые, объясните за что минусуете? за одну лишь опечатку в транслитерации фамилии? ведь Шрёдингер в мысленном эксперименте с котом подчёркивает вывод аналогичный выводу из неопределённости Гейзенберга — заключение, что явления квантового мира, как и все зависимые от них последствия, бывают очень ограничены в предельно возможной точности прогнозирования. согласен, гайзенбаг лаконичнее, но и со Шрёдингером пароним улыбнул.
not_ice
30.08.2016 18:52+3Был у меня гейзенбаг, в районе 98 года.
Тогда у меня был Пентиум 200, если кто помнит, в АТ-блоках питания был не только вход, но и выход на монитор.
Естественно, для пущего удобства туда был включён сетевой фильтр, куда воткнут помимо монитора усилитель Вега с советскими 35-ваттными колонками (ну потому что это удобно — включил комп и сразу все что нужно включилось).
Баг заключался в том, что при прослушивании музыки комп иногда перезагружался.
Естественно, когда через полгода усилок был вместо АТ-выхода воткнут в обычную розетку, все прекратилось :)Jef239
31.08.2016 00:50+1У меня комп зависал (1993 год) от включения-выключения холодильника. Перезапускался процессор клавиатуры, причем первую стартовую последовательность он выдавал не полностью. BIOS от этого шизел и закрывал прерывания от клавиатуры. Пришлось писать программу для открытия прерывания и запускать её мышкой. :-)
stychos
31.08.2016 03:51У меня и сейчас при включении света на кухне, на пару секунд выключается монитор в спальне.
avost
31.08.2016 06:37Железячной проблеме — железячное решение. Тоже холодильник на что-то влиял. Спасло найденное в хламе большое ферритовое кольцо — мотаем сетевой шнур холодильника через кольцо столько витков, сколько влезет, и — вуаля! Заодно пропадают щелчки в колонках. Впрочем, ещё лучше помогает смена совкой алюминиевой проводки на медную. Это, конечно, стены долбить, зато заодно пожаробезопачность повышается.
А у знакомых физиков такой «сетевой фильтр» был сделан из ферритового кольца диаметром сантиметров 30. Спасал компьютер от перезагрузки при включении рядом мощного генератора электронных пучков.Jef239
31.08.2016 15:55По миганию лампочек я решил, что это просадка напряжения, а не импульсная помеха. Но, может и неправ был.
Переключение компа на другую пробку не помогло. Так что провода, если менять — так от лестничных шин к щитку.
cybernomix
30.08.2016 20:00-1Еще я считаю что гейзенбаги — как ни странно — растут именно с ростом скилла разработчика, которые начинают юзать все более ловкие и «умные» конструкции в программировании, что и порождает таких баг-монстров. Более «тупой» или «декларативный» стиль, пусть и выглядящий порой более скучно и уныло — на деле же редко породит такие баги.
mayorovp
30.08.2016 20:34"Декларативный" стиль и отлаживать-то невозможно — так что да, гейзенбагов (т.е. багов, которые исчезают или проявляются в отладчике) в нем допустить сложно.
cybernomix
30.08.2016 23:50-1Остроумие не засчитано. Стиль != язык. Декларативный стиль это например использование более многословных конструкций switch case, чем хитроумных условий, особенно многовложенные одстрочные тернарные условия, как у js.
Что нить типа такого:
smallestNum = (x<y && x<z)? x: (y<x && y<z)? y: (z<y && z<x)? z;mayorovp
31.08.2016 05:50switch case — это вполне себе императивный стиль
cybernomix
31.08.2016 11:59хорошо, со switch case — пример не удачный, просто понятие «декларативности» в обиходном сленге расширилось, но вы цепляетесь за слова, вт вам пример про декларативный стиль языков программирования типа Lua, а не только языков разметки. (И да это особенно удобно когда погружаешь программный язык в какой-то язык разметки — просто в статье частный случай).
Основы декларативного программирования на Lua
cybernomix
31.08.2016 12:05+1«Декларативный» стиль и отлаживать-то невозможно
Да щито вы говорите?
Стыдно должно быть за попытку выглядеть умным, но не знать что такое декларативный стиль не в языках разметки.
Императивный стиль
int F(int x) { return x*x; } int sum = 0; for (int i=0; i<arg.Length; i++) { if (arg[i] > 10) sum += F(arg[i]); }
Декларативный стиль
int F(int x) { return x*x; } int sum = arg.Where(x => x > 10).Sum(F);
Source: Императивный vs Декларативный стильmayorovp
31.08.2016 12:43То, что вы привели — это не декларативный, а императивный стиль с элементами функционального.
cybernomix
31.08.2016 12:48Упрямство юного минусатора выше желания принять факты.
Wikipedia:
К подвидам декларативного программирования также зачастую относят функциональное и логическое программирование — несмотря на то, что программы на таких языках нередко содержат алгоритмические составляющие, архитектура в императивном понимании (как нечто отдельное от кодирования) в них также отсутствует: схема программы является непосредственно частью исполнимого кода[1].
А есть «чисто декларативные» языки типа SQL/HTML.
Вы спорите с академическими фактами, а не со мной.
На повышение уровня декларативности нацелено языково-ориентированное программирование.
Декларативность это более широкое понятие, которое описывает процесс c проекции «каково нечто», а не «как его создать». Порядок выполнения и способ достижения не важен.mayorovp
31.08.2016 12:52А есть «чисто декларативные» языки типа SQL/HTML.
Подскажите, пожалуйста, SQL-отладчик.
К подвидам декларативного программирования также зачастую относят функциональное и логическое программирование
Чистое функциональное программирование — да, декларативно. Но императивное программирование с элементами фугкционального остается императивным.
cybernomix
31.08.2016 13:03-1Подскажите, пожалуйста, SQL-отладчик.
Если потрудитесь отматать в начало треда, то речь шла о коде в «декларативном стиле», а не о «декларативных языках», которые мне пришлось упомянуть, чтобы вернуть вас с Луны на Землю.
Чистое функциональное программирование — да, декларативно. Но императивное программирование с элементами фугкционального остается императивным.
Попытка до упора отстоят свое, пусть и ошибочное изначально замечание — умиляет.
Ясно же, что сначала для вас было открытием «декларативный стиль» != «декларативный язык».
А теперь вы пытаетсь съехать, когда вас ткнули в академические формулировки.
Пора тредик закрывать — иначе он скатывается во флейм.mayorovp
31.08.2016 14:01Декларативный стиль — это описание "что желаем получить", в противоположность "что делаем" императивного стиля.
На C# можно писать в декларативном стиле.
К примеру, известная ORM-библиотека Entity Framework предполагает именно такое описание для настройки отображения (да и сама концепция ORM по своей сути декларативна).
При этом процесс работы с БД через EF — императивен, в отличии от настройки отображения.
Также к декларативным библиотекам можно отнести:
- AutoMapper;
- IoC-контейнеры (как и саму идею IoC);
- XML-сериализацию/десериализацию (кроме той части, что идет через интерфейс IXmlSerializable);
- кучу мест в ASP.NET MVC, которые настраиваются через атрибуты.
Вот это все — и есть декларативный стиль. А приведенный вами кусок кода
arg.Where(x => x > 10).Sum(F);— типичный императивный вызов.cybernomix
31.08.2016 16:21-1По сути треда:
Так вы отказываетесь от своих слов что декларативный стиль нельзая отлаживать?
Я вам привёл ссылки на академические/мета-академические (вики) источники — и примеры скопипастил из них, дабы не порождать флейма. Можете поспорить с авторами. Или как это часто бывает — создать свою альтернативную вселенную, в которой все ваши аргументы будут логичны и правильны, а оппонента — нет.
Вроде бы человек вроде вас должен трепетно относиться к железной логике конструктивизма.
Я вам привёл дословную цитату:
К подвидам декларативного программирования также зачастую относят функциональное и логическое программирование.
После этого тред можно закрывать.
Но вы с упорством, достойным лучшего применения, пытаетесь за что-нибудь зацепиться и сделать хорошую мину при неудачном изначальном остроумии про «невозможность отлаживать декларативный стиль».
Глупо, потому что вы думали до этого иначе. А теперь вот подчитали на скорую руку и с пеной оправдываетесь.
Надо уметь проигрывать и признавать ошибки. Вот и всё.
P.S.:
Ваша попытка сделать удачную мину при неудачном остроумии — засчитана, но не суть вашего изначального выпада.
MichaelBorisov
30.08.2016 23:10+2Изучая код разработчиков действительно высокого класса, можно заметить, что такой код не изобилует хитрыми трюками, а наоборот, выглядит очень красиво и понятно. Например, мне очень нравится изучать код ядра ReactOS (копирует структуру ядра Windows) по этой причине.
Ловкие и хитрые конструкции в коде — это удел специалистов среднего уровня, которые изучили трюки, но еще не накопили опыта и интуиции в том, когда следует их применять, а когда — нет.cybernomix
30.08.2016 23:53Высокого — да. Это те, кто прошли последнюю ступень искушения «использую, потому что могу» и перешли в стадию просвещенных «не использую, потому, что знаю».
michael_vostrikov
30.08.2016 21:38+1При открытии веб-приложения появлялось сообщение об ошибке БД, что id пользователя при вызове процедуры равно null. Сообщение было замечено пользователями при работе на тестовом сервере, потому что там все ошибки выводились через flash messages на фронтенд в виде всплывающих сообщений. Ошибка появлялась один раз на странице логина, при первом входе в систему, обычно с утра. Неавторизованного доступа в приложении нет.
Я нашел функцию, где происходит ошибка, функция вызывается из стандартного шаблона представления (layout), в котором по бокам разная информация для пользователя, в ней происходит вызов процедуры БД, куда передается user_id. Но он не может быть null, null он только на странице логина, а у нее свой шаблон.
В Firebug кроме GET-запроса страницы логина никаких других запросов к сайту нет.
Опытным путем выяснилось, что ошибка также появляется, если нажать Ctrl+F5 или Ctrl+Shift+R.
ПричинаОткрыл Chrome, и сразу нашел причину. На запрос favicon.ico выдается 404.
Firebug запрос фавиконки вообще не показывает.
При открытии сайта браузер запрашивает файл favicon.ico.
На тестовом сервере его почему-то нет, и на рабочем тоже.
Управление передается на index.php, приложение не находит подходящий роут и показывает ошибку 404.
Ошибка выводится со стандартным layout.
Текущего пользователя еще нет, база выдает ошибку, ошибка попадает в flash messages.
Открывается страница логина, показывает все flash messages из сессии.
Fedcomp
30.08.2016 22:40А логи запросов не велись?
michael_vostrikov
31.08.2016 08:40Велись наверно, но проблема была явно в приложении, а сообщение приложения и так отображалось в интерфейсе. А локально все работало, так как иконка была в репозитории.
Jef239
31.08.2016 01:00-1Аналогично бывает на завершении приложений. Система логгирования уже завершилась, возникает баг, она реактивируется, но криво. Это такое общее место для возникновения проблем.
Amomum
31.08.2016 00:57+4Отлаживал девайс с гироскопом, подключенный по com-порту к самописной программе на компе, которая угол отображает. Сижу, кручу девайс, все вроде работает. И вдруг хоп — в com-порте тишина.
Перезапустил прогу и девайс — все ок. За день это повторилось раза два или три, на первый взгляд, совершенно бессистемно.
В конце концов заметил, что это происходило, только если угол наклона девайса был 19 градусов…
ОказалосьОказалось, что я зачем-то (совершенно не понимаю — зачем?!) включил программное управление потоком com-порта, в котором байт 19 (0x13, XOFF) означает «Остановить передачу». Протокол у меня был бинарный, угол передавался просто двумя байтами в градусах. Девайс выдавал данные только по запросу, а после байта 19 порт на компе больше никаких запросов отправлять не хотел.temujin
31.08.2016 08:18Вот это уже классический гейзенбаг. Обнаружили проблему по наитию или путем пошаговой проверки?
mayorovp
31.08.2016 09:20+2Это обычный труднообнаружимый баг. Но он не меняет свои свойства при попытке обнаружения — а потому гейзенбагом считаться не может.
Amomum
31.08.2016 12:51Если я правильно помню, то где-то с третьего-четвертого раза я заметил, что последний показанный угол всегда один и тот же.
Jef239
31.08.2016 01:07+3Как пишут установку бита программеры? 1 << N, вроде без вариантов? А вот математикам роднее 2.0**N. На IA32 — вещественная арифметика 80 бит, так что все работало штатно. Лет через 5-10 после написания перенесли на ARM. И для N=31 оно начало сбоить — 2.0**N выдавало на единичку меньше, то есть все биты, кроме нужно.
N=31 это спутник G32 (GPS), в Питере он бывает виден редко, а вот на демонстрация в Москве — частенько. Так что дома все работало, а на демонстрациях — иногда был генеральский эффект.
Нашли чтением кода через 3 года после первого сбоя. И дня через 2 после начала охоты на этот баг. Воистину неуловимый Джо — это Джо, которого никто не хочет ловить.avost
31.08.2016 10:32+1Тут не в привычности дело, автор сего, похоже, в принципе не понимал, как числа в компьютере устроены. Попробовал 2**32 — ой, «почему-то» не работает. А что если… 2.0**32 — О! Заработало!
Jef239
31.08.2016 15:50-1Математически 1<<N, 2U**N и 2.0**N идентичны. И автор решил, что оптимизатор эту математическую идентичность поймет. И может быть оптимизатор даже и понял бы… Но… поскольку это был перенос сложного кода с IA32 на ARM плюс с С++ Builder на gcc плюс с Windows на linux, оптимизатор был отключен. Ускорение оптимизатор дает процентов 5-10, а вот шансы словить хитрый баг с ним больше. Поэтому компилятор отработал по принципу «слушайте ваши Валенки и не выпендривайтесь».
Интереснее, что человек может быть отличным алгоритмистом и отвратительным кодировщиком одновременно.
Что касается понимания чисел — меня всегда удивляло, как она может, глядя на значение чисел в матрице сказать, какой баг был допущен в обработке. Причем в процентов 95 — подтверждается.
avost
31.08.2016 16:54+1>Математически 1<<N, 2U**N и 2.0**N идентичны. И автор решил, что оптимизатор эту математическую идентичность поймет.
«не думаю» (ц) :)
Сознательно написать число с точкой в надежде, что оптимизатор превратит его в целое… Как-то неправдоподобно. Но, даже, если ход мысли был именно такой, это всё-равно принципиальное непонимание как числа в компьютере устроены. Даже если оптимизатор превратил бы 2.0 в 2, ошибка бы была и на IA32. Там ведь у сибилдера целые тоже 32-х битовые. Поэтому, видимо, точку добавили именно потому, что без точки не работало, а понять почему не работало, не осилили.
Впрочем, не важно, история сама по себе интересная.Jef239
31.08.2016 22:11-1Отличие в том, что вы ДУМАЕТЕ, а я ЗНАЮ. Под 100 тысяч строк этого автора поддерживаю.
Да, для программиста оптимизация pow(2,N) в целое — маловероятна. И у программеров есть понимание, что pow(2,N) и pow(2,0,N) — одно и тоже, ибо аргумент у pow вещественный. И есть понимание отличий внешних от внутренних функций. Внутренние — это функции вроде sqrt, которые могут быть оптимизированы до машинной команды. А pow — внешняя, даже pow(x,2) не оптимизируется до x*x.
> Даже если оптимизатор превратил бы 2.0 в 2, ошибка бы была и на IA32
АРГУМЕНТИРУЙТЕ. Желательно тестовым примером. Или доказательством, что 56 бит на IA32 мантиссы мало.
> точку добавили именно потому, что без точки не работало, а понять почему не работало, не осилили.
Значит тоже не понимаете, что pow(2,N) и pow(2,0,N) дает одинаковый код.avost
01.09.2016 09:15+1А, так у вас нормального возведения в степень нету, только pow есть. Что же голову с 2**N морочили? :)
>> Даже если оптимизатор превратил бы 2.0 в 2, ошибка бы была и на IA32
>АРГУМЕНТИРУЙТЕ. Желательно тестовым примером. Или доказательством, что 56 бит на IA32 мантиссы мало.
Это вы меня смутили операцией **, я си давно забыл, думал, что там есть такая. С pow-то понятно, фактические аргументы будут приведены к типу формальных.
>Отличие в том, что вы ДУМАЕТЕ, а я ЗНАЮ. Под 100 тысяч строк этого автора поддерживаю.
Вы продолжаете утверждать, что автор знал устройство чисел в компьютере? Вроде, довольно очевидно, что не знал. Тем, кто знает и в голову не приходит использовать вещественную арифметику в виде целочисленной, надеясь на оптимизатор. Тем более, в таком простом случае. Про оптимизатор я теперь даже затрудняюсь понять что вы про него имели в виду. Довольно очевидно, что оптимизатор вряд ли станет оптимизировать вещественную функцию в целочисленную. За токое канделябром бьют.Jef239
02.09.2016 03:59> Это вы меня смутили операцией **, я си давно забыл, думал, что там есть такая.
я тоже забыл. :-)
> Довольно очевидно, что оптимизатор вряд ли станет оптимизировать вещественную функцию в целочисленную.
ДА НУ?
const int four = 2.*2.;
Получаем mov [ebp-0x04], 0x00000004
Если компилятор сумеет просчитать функцию с константными аргументами при компиляции — он вполне оптимизирует вещественную функцию в целый результат.
> За токое канделябром бьют.
Ну бейте. Компилятор Borland C++ Builder
> Тем, кто знает и в голову не приходит использовать вещественную арифметику в виде целочисленной, надеясь на оптимизатор.
Как видите — оно даже работает.
Но чтобы отличить, где оптимизация сработает, а где нет — нужно понимать хотя бы отличие внутренних функций от внешних. А вот это математик не знала.
> Вы продолжаете утверждать, что автор знал устройство чисел в компьютере?
ДА, разумеется. Думаю, что о накоплении ошибок в вычислительных алгоритмах она знает побольше вас. Просто возможности компилятора не понимает.avost
02.09.2016 04:29>ДА НУ?
>const int four = 2.*2.;
>Получаем mov [ebp-0x04], 0x00000004
А где здесь функция? Вы уровня сложности pow напишите. Она же степени через экспоненты считает?
>Ну бейте. Компилятор Borland C++ Builder
Этого даже бить не надо. Само помрэ.
>Как видите — оно даже работает
Вы убедительно доказали, что оно НЕ работает.
>Но чтобы отличить, где оптимизация сработает, а где нет — нужно понимать хотя бы отличие внутренних функций от внешних. А вот это математик не знала.
Нет. Для решения этой проблемы надо знать лишь устройство чисел в компьютере и всё. Основы. А ваше деление на внутренние и внешние — это какое-то местечковое сибилдерное шаманство? Вот его точно знать не надо. Его даже гуголь не знает. А код, зависящий от знания способа оптимизации компилятора == говнокод. Тем более, в случае такой банальщины.
>Думаю, что о накоплении ошибок в вычислительных алгоритмах она знает побольше вас. Просто возможности компилятора не понимает.
Ну, продолжайте пребывать в этой ложной уверенности. А лучше дайте «ей» что-нибудь уже почитать. Да и сами не пренебрегайте. В конце концов, это вам, не мне, разгребать 100к+ говнокода, написанного без какого бы то ни было понимания. «я могу писать со скоростью 400 знаков в минуту, правда такая фигня получается...».
Barafu
31.08.2016 09:52+9Расскажу вам об эпическом баге, который поразил нашу команду 5 лет назад. Ввиду специфики темы придётся некоторые подробности опустить.
Разрабатывали комп для военных. Разработали. Всё работает. Весит, правда, как новорожденный буйволёнок, но это не наша вина. (Зачем-то наши вояки для всех устройств требуют работоспособность при -60С. И действительно её проверяют. За счёт одного этого устройство весит в 3 раза больше, чем могло бы при -20С, и главное никому нафиг не нужно это).
В качестве сдачи заказчику — участие взвода с нашей системой в больших учениях в полях. Взвод с нашей системой и 10 со старой. Средство связи у всех взводов, включая наш, одинаковое — такая рация с функцией передачи цифровых данных. Давным давно у этой рации мы обнаружили забавный глюк — она не передаёт сообщения длинной 31 байт. Больше или меньше — да. Ну да ладно, учли это в коде и вроде работает. Прямо за полчаса до начала учений всё проверили, всё работает.
Раздаётся приказ к началу учений, и тут у нас пропадает связь. Вся, разом, как накрыли медным тазом. И в течении 5 часов связи не было. Раздался приказ об окончании учений. И сразу хренак! Всё снова работает. Потом были долгие разборки-штрафы-санкции, но по сути это событие закрыло компанию, где я работал.
И только через месяц мы как-то по наитию догадались, в чём дело. В API на передачу пакета данных в рацию есть поле «приоритет». По документации значение от 1 до 10, 1 — самый главный. Ну мы и поставили 1 для сообщений писец-класса, 2 для класса срочных и так далее. Наивные. В старой системе же стоял приоритет 1 для всего вообще, включая телеметрию. Поэтому когда вокруг было 10 раций со старой системой, всё работало. А вот когда их стало 500 — на нас просто не хватило эфирного времени.
То есть косяк был даже не наш, но в армии, сами знаете, это ничего не значит. Отака фигня.
Итог: я просидел 5 часов на ящике с гранатами при -15, и с тех пор сыплю фразами типа «если этот сервер поддерживает одновременно 400 абонентов, это ещё не значит, что он поддержит и 350»
Tar
31.08.2016 12:24+4Баг в давнишней игре под старые телефоны (brew). В игре можно было менять цвет одежды персонажа. Тестеры обнаружили, что если выбрать русский язык, то цвет одежды менялся слабо и всегда был какой-то серый и тусклый. Баг долго отпинывали, потом решили разобраться.
Вообщем после исследования обнаружилось, что слово «продолжить» несколько длиннее слова «continue» и своим хвостом залезает в кусок памяти с цветом одежды.
we1
31.08.2016 14:07-1Была такая проблема много лет назад. В программе получался косяк, но многократная тщательная проверка кода ничем не помогала. Оказалось, что надо было отключить оптимизиацию в компиляторе. Очень помучался тогда с этим.
mayorovp
31.08.2016 14:16Скорее, не надо было допускать в коде UB. Отключение оптимизации — это костыль, приемлемый для старого кода, но говорить "надо отключить оптимизацию" нельзя. "Надо" только исправить код.
we1
31.08.2016 16:26Не знаю что такое UB. Там было очень много условных ветвлений и вложенных циклов. Если бы я знал в чем именно проблема, то попытался бы упростить. Но насколько я помню, особо там упрощать было нечего.
mayorovp
31.08.2016 17:38+1UB — это undefined behavior. Ситуация, в которой, согласно стандарту языка, компилятору разрешено делать что угодно. Современные оптимизаторы считают такую ситуацию невозможной и оптимизируют код исходя из этого
Обычно это означает выкидывание условий, которые оптимизатор счет невозможными.
К UB относятся ситуации целочисленного знакового переполнения, разыменования нулевого указателя, бесконечный цикл.
Вот одна из статей на эту тему: https://habrahabr.ru/company/pvs-studio/blog/276657/
we1
31.08.2016 18:57Пробежал статью. У меня точно такого не могло быть. Код был совершенно тупой без изысков. Просто много уровней вложенности.
mayorovp
31.08.2016 19:10Значит, было что-то другое. В статье рассказано только про один вид UB.
Jef239
01.09.2016 00:50-1Вам же явно описали — при попытке перестановки условий (а всего вариантов — порядка N факториал) оптимизатор запутался. Возможно — переполнение внутренних таблиц, возможно — srict aliaing сработал.
Вообще-то этот пример раньше на начальных курсах института проходили. Компилятор FORTRAN OE, IBM 360/370. Псевдокод основной идеи на Си.
if (div != 0)
Res = sum /div;
else {
div = 1;
Res = sum /div;
};
Оптимизируя общие подвыражения, оптимизатор сделал так
Res = sum /div;
if (div == 0)
div = 1;
Угу, общие подвыражения он вынес. Но с водой потерял и ребенка. Пример классический, многократно описан в книгах. Стыдно такое не знать.mayorovp
01.09.2016 07:06Нарушение strict aliasing — это UB.
Jef239
01.09.2016 15:08-1ОК. А теперь со ссылкой на стандарт докажите, что в С++ запрещено реализовывать двухсвязные списки (на каждый элемент есть две ссылки — у предыдущего и следующего члена в списке), деревья (много листьев ссылается на предыдущий уровень дерева), графы и так далее.
Ну или признайтесь, что несколько поторопились.
Jef239
01.09.2016 00:31Вера в безошибочность компилятора обычно крепка только до написания своего первого компилятора. :-) А потом начинаешь понимать. Компиляция компилятором самого себя — это тестирование примерно 30% языковых конструкций. Компиляция ядра линукс — процентов 50. А все остальное — в простых примерах работает, а вот сложные комбинации — не тестированы
Для недоверчивых — https://gcc.gnu.org/bugzilla/buglist.cgi?quicksearch=optimization 2231 баг, связанный с оптимизацией, некоторым багам — уже больше 10 лет.
Так что UB иногда бывает, но баги оптимизации встречаются чаще. Вот ещё статья с примерами https://habrahabr.ru/post/114117/ к чему приводит strict aliasing.
Что касается пользы от оптимизатора — она процентов 5-10. Если больше — значит программист надеется на оптимизатор и пишет неэффективно. С другой стороны, переделка алгоритмов дает выигрыш в разы, в моей практике — и в тысячи раз.
UB править стоит — но не фанатично. Ибо в виндосовских хеадерах UB более, чем хватает. Как пример — преобразование беззнакового в знаковое того же размера. Иногда даже компилятор ругается (warning или hint) на особо наглый код. Суть в том, что если вы попадете на машину, где используется прямой или обратный код — вашей программе будет плохо. Но с вызовами виндовскими хеадерами — будет так же плохо. Иными словами — на такой машине windows все равно работать не будет и ваш код там бесполезен.
По моим оценкам отказы оптимизации
30% ошибка программиста
5% тонкие эффекты изменения точности
65% баги оптимизатораmayorovp
01.09.2016 07:08+1А если не верить компилятору — программирование не имеет смысла.
Jef239
02.09.2016 03:10-1Знаете — программирование вообще занятие для не верящих. Потому что даже в процессор верить на 100% не стоит.
Как пример 2.0 было равно 16.0 в одной из ранних ЕС-1036. В микрокоде вещественные числа на равенство сравнивали по мантиссе. И забыли сделать сравнение ординаты.
Ещё пример. комп (М6000) иногда портил файловую структуру диска. Длительное расследование показало, что во время длиной (на пару страниц) процедуры поиска дорожки и сектора в бите С (бит целочисленного переполнения) держится тип операции: чтение или запись. Но что-то в процессоре иногда сбоило и вместо бит С менялся той командой, которая его менять не должна была.
Та же машина как-то раз после старта попросила включить перфоратор и вывела на перфоленту «Можете ли вы длительное время выполнять нужную однообразную работу, например считать или переводить с иностранных языков?» После этого она демонстративно сломалась.
Чтобы не думали, что баги были только на древних процах -Pentium-III, производства Малазии имел обыкновение зависать при уменьшении рабочего набора. Починили заменой процессора. скорее всего причиной — трещина в кристалле. Но все тесты он проходил на ура.
Можете для повышения кругозора посмотреть errata на современные SOC-чипы. Там тоже немало.
А уж ошибок в компиляторах — ВАГОНЫ. Их в сотни раз больше, чем ошибок в процессорах.
Это как со слоном — то, что вы никогда не видели слона — не означает, что слон не существует. Это означат, что вы ходите по одним местам, а слоны — по другим.
Так что пока вы копируете стили из учебника — все будет более-менее хорошо. Как только начнете думать сами, а не повторять чужие образцы — сразу вероятность нахождения бага в компиляторе увеличится.
Но верить в программировании — нельзя НИКОМУ — ни процессору, ни компилятору, ни ядру linux, ни господу богу. Нужно просто писать НАДЕЖНО. Так, чтобы ваши ошибки в коде не мешали работать остальным частям вашей программы.
https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=6.2 — список ошибок, исправленных в gcc 6.2. как писали в readme к одной популярной библиотеке «Исправлены обнаруженные ошибки, оставлены необнаруженные, добавлены новые.»
P.S. Могу ещё и про ошибки в ядрах linux и FreeBSD рассказать.
mayorovp
01.09.2016 09:57+1> Для недоверчивых — https://gcc.gnu.org/bugzilla/buglist.cgi?quicksearch=optimization 2231 баг, связанный с оптимизацией, некоторым багам — уже больше 10 лет.
Первые 10 багов по этой ссылке:
1. нет предупреждения в случае, когда функция, объявленная как pure или const, не является таковой;
2. вылет с OOM;
3. FP EMULATION медленнее чем в clang;
4. std::pow(std::complex(0),1) возвращает (Nan, Nan) в режиме -funsafe-math-optimizations;
5. генерируется неверная отладочная информация для конструктора и деструктора;
6. что-то с маркером для оператора return, использующимся при отладке;
7. неоптимальность преобразования fold_binary_op_with_conditional_arg;
8. отсутствие векторизации в определенном случае;
9. отсутствие оптимизации в некотором случае;
10. какое-то лишнее предупреждение.
Из этих багов только 1 может привести к генерации неверного кода — но только в режиме оптимизации, который еще надо специально включить.
И остальные незакрытые баги — такие же.Jef239
01.09.2016 14:52-12231 баг. Если верить вашей статистике (1 к 10), то это 223 бага при оптимизации. И намного больше разных проявлений одного и того же бага (дубли сводятся в один багрепорт). И огромное количество случаев, когда людям просто проще написать обход ошибки, чем багрепорт.
>только в режиме оптимизации, который еще надо специально включить.
Любуйтесь. https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Optimize-Options.html#Optimize-Options
-Ofast включает -ffast-math, -ffast-math включает -funsafe-math-optimizations
gcc — хороший компилятор, но как в каждой большой программе — там хватает ошибок.
Viacheslav01
31.08.2016 15:11+2Мой любимый, у коиентов работающих под VMWare временами вместо меню были красные кресты, обычное дело если ты упал гденибудь в процессе рисования. Но элемент стандартный, а крест есть, и не у всех клиентов, и имеет свойство пропадать/появляться без обновления приложения. Долгие раскопки привели к тому, что в многоэкранных конфигурациях, VMWare объединяет видео пространство в одно целое.
С одним интересным эффектом, если первый логический монитор в левом нижнем углу то проблем нет, а если в любом другом положении, то на вопрос о мониторе по умолчанию, приходит ответ, что нет монитора по умолчанию.
Баг чинился у клиентов очень просто перестановкой мониторов и почти всегда вызывал полнейшее недоумение :)
allex
31.08.2016 16:59+1В копилку:
Это было моё первое задание, когда году в 1998м я пришел устраиваться на подработку эникейщиком. Было там пять совершенно одинаковых компьютеров отвратительной конфигурации – процессор AMD K5 100 непонятно на какой материнской плате, 16 мегабайт памяти, видеокарта AliMagic и гигабайтный винчестер Samsung.
Так вот, на один из этих компьютеров программа 1С: Предприятие 7.5 прекрасно устанавливалась, а на второй нет. Инсталлятор вылетал с ошибкой на скольких-то там процентах и всё. Не помогала даже переустановка Windows на чистый диск. Я просто поменял жесткие диски местами. Вот и попробуйте угадать, как куда программа после этого устанавливалась, а куда нет.
ОтветОна установилась на оба компьютера!
Почему? А кто её знает… Я ж говорю – проще решить проблему, чем найти объяснение феномену.temujin
31.08.2016 17:57Этому должно быть какое-то теоретическое объяснение, но мне ничего не приходит в голову. А что Вас надоумило поменять местами жесткие диски?
allex
31.08.2016 22:18Пытался локализовать проблему. Но результат эксперимента поставил меня в тупик :) Заказчика устроило, дальше экспериментировать не было возможности, железо пошло в бой. Я вообще удивляюсь, как там что-то работало — компьютеры пережили потом в помещении (их не залило, но следы коррозии от повышенной влажности были), потом ремонт с пылью.
asurkis
31.08.2016 17:572 года назад пытался помочь своему однокласснику со школьным заданием по информатике. Суть в том, что при прогоне через отладчик узнали, что в приложениях на PascalABC.NET именно этот комп в качестве результата операции 7 + 1 возвращал 9. Баг больше не воспроизводился никак — исключительно на конкретном компьютере, под конкретным аккаунтом и только в PascalABC.NET, но при этом не зависел от Release/Debug-конфигурации
Jef239
31.08.2016 22:17Стандартный налет в разных навигаторах — в 3 часа ночи с субботы на воскресенье координаты улетает на несколько сотен метров и машина едет прямо через дома. Продолжается от 15 минут до часа. Причина — смена номера недели GPS (эфемериды на старую неделю, а время от новой). но для непосвященных — очень странный глюк.
allex
31.08.2016 22:20Так рождаются суеверия — не ездить на машине в ночь с субботы на воскресенье :)
Jef239
31.08.2016 22:49+1Скорее быть готовым к тому, что навигатор поедет через дом или потребует свернуть на мост, снесенный паводком лет 20 назад. Мы так чуть в аварию не попали — водитель очень хотела по навигатору ехать, а он вел прямо в реку.
Deosis
01.09.2016 08:57+1Насчет номера недели, он переполняется примерно раз в 19 лет. Последний раз было в начале этого года.
Если оборудование брало время оттуда, то происходил сбой.
Существую ли способы найти баг, который воспроизводится раз в N лет?Jef239
02.09.2016 00:05> Существую ли способы найти баг, который воспроизводится раз в N лет?
ДА. Внимательным чтением кода находится и не такое.
> Если оборудование брало время оттуда, то происходил сбой.
Нет, причина не в этом. TOW (время он начала недели) сбрасывается в 0 при смене недели. А эфемериды в момент смены недели не меняются, действуют те, что приняты на старой неделе. Если специально не учесть этот момент и не добавить 604800 к текущему времени, расчет эфемерид происходит на начало предыдущей недели.
> Насчет номера недели, он переполняется примерно раз в 19 лет.
Для расчета координат это не важно. Для теплого старта — хватит 3-4 бит номера недели (альманахи старше месяца лучше не использовать). Реально в альманахах — 8 бит.
Важно это для показа даты, но там или опираемся на ГЛОНАСС-М (там есть номер четырехлетия) или на ГЛОНАСС (день внутри четырехлетия и его совпадение с датой по GPS) или используем L2 (там 13 бит номера недели, то есть переполнение раз в 157 лет) или на SRAM (часто вместе с RTC).
Иными словами в приемниках GPS/ГЛОНАСС ошибка раз в 19 лет крайне маловероятна, а вот в приемниках чистого GPS — она может быть (особенно при сдохшей батарейке).
Это я ещё не глянул стандарт на SBAS…
hdfan2
01.09.2016 17:25+3Чудесная сказка Bormor'а в тему— Послушай, — обратился демиург Шамбамбукли к пророку. — У меня для тебя есть важное поручение.
— Какое?
— Пойди в землю, которую я тебе укажу, собери там всех рыжих и вели им никогда не есть крокодилов.
— Чего!?
— Не важно. Просто передай это, и всё.
Пророк задумчиво почесал в бороде.
— У этой заповеди есть какой-то высший смысл? — спросил он. — Доступный человеческому пониманию?
— Конечно, есть! — воскликнул Шамбамбукли. — Сейчас объясню. Посмотри на небо. Видишь звёзды?
— Вижу. А что с ними не так?
— Хотел бы я это знать, — вздохнул Шамбамбукли. — Понимаешь, звезды управляют всевозможными процессами на земле, у каждой из них своя важная функция в этом мире. Ну так вот, обрати внимание на те три звезды; я заметил, что когда кто-нибудь рыжий ест крокодила, пусть даже маленький кусочек, их функции выдают неверные значения. А это приводит к ошибочной индексации памяти, в результате которой… впрочем, тебе незачем знать технические подробности. А мне, сам понимаешь, проще дать лишнюю заповедь, чем переделывать всё мироздание. Эти космические взаимодействия так перепутаны…
— Но почему запрет касается только рыжих?! Почему только им нельзя питаться крокодилами?
— А вот это, — сказал Шамбамбукли, — меня самого очень интересует.safinaskar
01.09.2016 17:53По поводу последнего бага, вашего личного. Если проблема проявляется на одной системе и не проявляется на другой (live), нужно понять, чем системы отличаются. Сделайте, скажем, diff между списками установленных пакетов (с версиями) или между системами целиком. Вообще, смотрите. В live бага нет. Значит, скорее всего, если сделать чистую установку с теми же пакетами (с версиями) (продолжение в следующем посте)
safinaskar
01.09.2016 17:58, что и в live, то бага не будет. Затем начните приближать друг к другу две эти системы (в которой есть баг и в которой нет), пока не поймёте в чём дело. Я так успешно находил баги. Да, по идее авторы софта должны это делать за вас. Но, к сожалению, в мире свободного ПО баги вообще редко фиксятся, а тем более баги с непонятной причиной. Так что пока вы не найдёте источник вот таким вот образом, никто ваш баг чинить не будет
catnikita255
Я вчера встретил гейзенбаг, хотя, может, это была моя ошибка. Функция таймера крашила систему, если в ней был вывод, то есть от наблюдения и сообщения зависил результат работы. На самом деле ничего сверхъественного: printf, кажется, портил память или очень много ее тратил. Все встало на круги своя, когда я сменил printf на простую функцию вывода у терминала.