Отладка *

В 1971 году СССР доставили на Марс первые в мире планетоходы «на лыжах», которые должны были щупом (динамический пенетрометр и гамма-лучевой плотномер) ткнуть поверхность, и сказать — Марс твердый или жидкий пыльный. Первый аппарат разбился 27 ноября, второй совершил мягкую посадку 2 декабря, но марсоходик не смог выбраться из «скорлупы» посадочного модуля, поэтому попытку не засчитали.

Прошло 25 лет.
4 июля 1997 года на Марс прилетел американский аппарат и привез «пришельца» с первым багом.


Кадр из к/ф «Марсианин». Главный герой держит в руках марсоход Sojourner

Проект был под угрозой, но мощные инструменты отладки операционной системы и отличная работа программистов на Земле (парни, что надо) позволили в кратчайшие сроки все быстренько исправить.

Чем сложнее программный продукт, чем больше он взаимодействует со сторонними системами (часто не менее сложными), тем выше вероятность сбоев в работе. Тестирование помогает найти большинство багов перед выкатыванием релиза, но иногда что-то может проскользнуть. И чтобы быстро получать подробную информацию о факте сбоя и сопутствующих условиях, в наших продуктах широко используется система отчётов. О её устройстве мы хотим сегодня рассказать.

Как провести связь третьего и четвертого поколения туда, где в ходу лишь 2G из-за того, что горы мешают прямой видимости базовых станций, а для установки дополнительных БС нет необходимых энергомощностей? Наш эксперт Константин Кильбер расскажет о соответствующем опыте компании МТС – на примере установки активного ретранслятора для радиорелейной линии в маленьком поселке в Республике Адыгея в 2015 году. Итак, передаем слово нашему специалисту.

Задача перед нами стояла непростая: обеспечить максимальную пропускную скорость от базовой станции в поселке Гузерипль, Республика Адыгея. Это такое место у подножия Главного Кавказского хребта, на высоте 670 метров над уровнем моря, с населением чуть более 100 человек.

Главной проблемой стали горы – они мешали прямой видимости радиорелейных станций (РРС), которые являются транспортной составляющей для базовых станций. Ранее был построен пассивный ретранслятор (без активного оборудования): две радиорелейные антенны, соединенные между собой волноводом. Сигнал от радиорелейной станции (РРС 1) приходит на одну антенну, через волновод сигнал попадает на вторую антенну, далее сигнал идет на вторую часть радиорелейной станции (РРС 2). Пропускная способность радиорелейной линии с пассивным ретранслятором составляла не более 30 Мбит/с, что для современной связи очень мало. При таком раскладе может работать только базовая станция 2G, а вот с 3G и LTE уже возникают сложности.

Продолжаем эксперимент, начатый месяцем ранее, когда мы построили Wi-Fi сеть с бесшовным роумингом и прошлись по офису с планшетом, наблюдая, будут ли происходить замирания и сбои при скачивании на него потокового видео? Эксперимент прошел удачно, проблем с потоком не было и отчет выложили здесь же на Хабрахабр. Но!

Но в комментариях к статье были выражены сомнения, ввиду того, что видеопоток мог буферизоваться и бесшовный вай-фай эмулировался за счет подкачки видео еще до перехода от одной точки доступа к другой и это видео, из буфера воспроизводилось после обрыва и восстановления сессии. Отвечая на эти вопросы мы снова нагрузили абсолютно ту же сеть, с теми же точками Edimax, ничего не меняя в их настройках (поднял те же параметры для другого SSID, чтобы не мешать офису со своими тестами по RADIUS серверу, который так же обкатываю для работы в этой сети). Использовали почти что голосовой трафик, который нельзя было заподозрить в буферизации. С удовольствием делимся результатами второй части эксперимента.

Как сделать ваш код лаконичным и послушным одновременно?

Вам когда-нибудь встречалось приложение, которое вело себя очевидно странно? Ну, вы знаете, вы нажимаете на кнопку и ничего не происходит. Или экран вдруг чернеет. Или приложение впадает в «странное состояние» и вам приходится перезагружать его, чтобы все снова заработало.

Если у вас был подобный опыт, то вы вероятно стали жертвой определенной формы защитного программирования (defensive programming), которую я бы хотел назвать «параноидальное программирование». Защитник осторожный и рассудительный. Параноик испытывает страх и действует странно. В этой статье я предложу альтернативный подход: Offensive programming.

«Ошибка в Pentium настолько специфичная, что обычный пользователь столкнется с ней раз в 27000 лет»
— руководство Intel

«Вот вам правдоподобный сценарий, когда пользователь будет сталкиваться с ошибкой каждые 3 миллисекунды»
— Воэн Пратт (дизайнер логотипа SUN и соавтор алгоритма Кнута-Морриса-Пратта)

66 MHz Intel Pentium (sSpec=SX837) with the FDIV bug

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

А теперь главный вопрос: «Чем занимался Томас Найсли с начала июня до конца октября 1994 года?»

11 февраля 1991 года Patriot Project Office получил израильские данные о дефекте в ракетной системе Patriot. Они нашли, что если система работает 8 часов, она начинает мазать на 20%. Они прикинули, что после 20 часов работы система начинает промахиваться настолько, что перестанет быть способной захватывать, отслеживать и поражать баллистические ракеты. Американские военные не приняли во внимание всю важность открытия, заявив, что система предназначена для портативных и краткосрочных защитных операций и что никто никогда не будет использовать систему больше 8 часов.

16 февраля был выпущен Bug Fix, но чтобы его внедрить во все единицы боевой техники, требовалось время, ибо война.

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

25 февраля в Дахране (Саудовская Аравия) в казарму в гости к американцам прилетела баллистичекая ракета "керосинка" (она же Р-17, она же Scud). 28 убито 96 ранено, потому что ЗРК «Патриот» промахнулся из-за программной ошибки.

26 февраля Bug Fix был доставлен в Дахран.

Мы не любим ждать в очереди, хотим сделать заказ онлайн, мы не готовы покупать билет в кассе, пусть все будет в приложении, в электронном виде. И вот тут есть важное «Но»! Мы всё хотим здесь и сейчас, но чтобы это работало без сбоев, как часы. Доставку пиццы осуществили вовремя, место в кинотеатре совпало с полученным в подтверждении. Что во всем этом многообразии приложений и сервисов играет одну из ключевых ролей?

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

Зачем все это было нужно и к чему мы пришли?
Какое будущее нас ждет?

Поговорим «за тестирование» с гуру профессии. Пройдёмся от А до Я по инструментарию. Помогут нам в этом Игорь Хрол и Антон Семенченко.

Запасаемся кофе, чаем, другими напитками и начинаем. Беседа будет долгой.

Итак, Игорь Хрол — специалист по автоматизации тестирования в Toptal. Игорь имеет большой опыт работы с большинством популярных инструментов (Selenium, HP QTP, TestComplete, JMeter).

В этой статье мы поговорим об ошибках, совершаемых программистами на Bash. Во всех приведённых примерах есть какие-то изъяны. Вам удастся избежать многих из нижеописанных ошибок, если вы всегда будете использовать кавычки и никогда не будете использовать разбиение на слова (wordsplitting)! Разбиение на слова — это ущербная легаси-практика, унаследованная из оболочки Bourne. Она применяется по умолчанию, если вы не заключаете подстановки (expansions) в кавычки. В общем, подавляющее большинство подводных камней так или иначе связаны с подстановкой без кавычек, что приводит к разбиению на слова и глоббингу (globbing) получившегося результата.

Целостность данных легко нарушить. Бывает так, что в поле price попадает значение 0 из-за ошибки в коде приложения (периодически всплывают новости, как в том или ином инет-магазине продавали товары по 0 долларов). Или бывает, что удалили юзера из таблицы, но какие-то данные о нем остались в других таблицах, и эти данные вылезли в каком-то интерфейсе.

PostgreSQL, как и любая другая СУБД, умеет делать некоторые проверки при вставке/изменении данных, и этим обязательно нужно уметь пользоваться. Давайте посмотрим, что мы можем проверять:

1. Кастомный подтип через ключевое слово DOMAIN

Люди: — Эй, Тойота, мы тут посчитали, у вас из-за корявой электроники и софта 89 человек погибло с 2000 по 2010.
Тойота: — Да они сами виноваты, путают педали.
Люди: — Хьюстон, у нас проблемы.
NASA: — Ща разберемся, нам надо 10 месяцев и 3 миллиона долларов.
Люди: — На.
Тойота: — 3 миллиона мало, вот вам еще сверху кэшем.
(прошло 10 месяцев)
NASA: — Эй, Тойота, мы у вас пару ошибок в коде нашли, а точнее 7134 нарушения стандартов MISRA, рекурсию, функцию на 740 строк и 9000 глобальных переменных.
Тойота: — А у нас свои стандарты. А вы ваще на Луну летали?
NASA (публично): — Тойота ни в чем не виновата.
(Акции Тойота подскочили на 4,6%)
Люди: — Ну ё-моё.
(спустя 3 года)
Два американских тестировщика (у которых дедушки погибли в Перл-Харбор): — Нет багов? А если найдем?

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

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



Здесь мы рассмотрим методику оптимизации вычислений, связанных с моделированием течений многофазных жидкостей в пористых средах по методике, предложенной в этой работе. Речь идёт о численном методе решения дифференциальных уравнений гиперболического типа в частных производных.

GDB — инструмент, без которого тяжело обойтись. Конечно, как говорит Брукс «Качество разработки программного продукта достигается благодаря правильному проектированию, а не бесконечному тестированию». Однако, правильное проектирование не защищает от логических ошибок, опечаток, нулевых указателей и так далее. И вот здесь нам и помогают инструменты отладки кода, такие как GDB. Моя цель показать, что не менее полезными инструментами являются статические анализаторы кода, выявляющие многие ошибки на самых ранних этапах. Намного лучше, если ошибка будет исправлена в коде, ещё до этапа тестирования и отладки. Для демонстрации пользы от статического анализа кода, поищем внутри GDB ошибки с помощью анализатора PVS-Studio.

Программный код начал убивать людей при помощи машин еще в 1985 году.



Типичная разовая терапевтическая доза радиации составляет до 200 рад.
1000 рад — смертельная доза. Восставшая машина фигачила в беззащитных землян 20 000 рад.

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

В Therac-25 аппаратная защита была убрана и функции безопасности были возложены на программное обеспечение.

Как проводилось расследование, что должны намотать на ус проектировщики ИТ-систем, программисты, тестировщики, чтобы не допустить подобного.

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

Прошло уже много времени с момента того, как мы научились разбирать архивы движка визуальных новелл Yuka, настало время взяться за самое интересное из того, что мы там нашли — собственно, скрипт. Забегая чуть-чуть вперед, сразу предупрежу, что скрипт, конечно, куда более сложная материя, чем просто архив с файлами, поэтому за одну статью нам с ним не разобраться, но сегодня мы попытаемся понять, из каких частей он состоит и получим доступ к текстовым ресурсам.

Перед тем, как погружаться в пучины бинарных дампов, давайте прикинем, как работают большинство движков визуальных новелл. Визуальная новелла сама по себе состоит из текста (реплик героев, диалогов, промежуточного повествования), графики и звуков. Для того, чтобы ее воспроизвести пользователю, явно нужно свести все это воедино с помощью какого-то управляющего воздействия. В теории можно было бы зашить это все прямо в exe-файл, но в 99% случаев (ладно, вру, в 100% виденных лично мной) так все-таки не делают, а хранят такие инструкции отдельно в виде отдельной программы-скрипта. Как правило, скрипт пишется на особенном языке программирования (специфичном для движка), который выглядит как-то так:

Луна убывает, такое бывает… ©Земфира

Гейзенбагом называют ту разновидность программных глюков, которая возникает не пойми откуда, не поддается отладке и обнаружению. Словом, ведет себя как тот самый Неуловимый Джо или кроковский кот из недавнего поста. Мне по работе приходилось сталкиваться с такими и про себя я называл это эффектом квантовой механики до тех пор, пока не узнал, что близкое по смыслу название уже давно придумали. Бывает, посылаешь заказчику отладочный бинарник, который всего лишь записывает в журнал больше событий вокруг предполагаемого источника проблемы и после этого проблема исчезает!

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 файле.

Буквально вчера выложил в открытый доступ первую рабочую версию консоли для отладки Canvas/WebGL приложений FConsole. Если вы всегда хотели редактировать свойства визуальных объектов без изменения исходного кода, а так же без сложностей просматривать всю иерархию визуальных объектов, то прошу под кат.


* На скриншоте представлена Flash-Console, которая бралась в качестве примера при разработке FConsole

2016 год ещё не кончился, но продолжает радовать нас крутыми продуктами по обработке изображений. Сначала все болели FaceSwap, потом появился MSQRD, теперь у нас есть Prisma. Ещё больше радости/гордости, конечно, от того, что последние 2 продукта — наши, родные. MSQRD делают ребята из Беларуси, Prisma же вообще родом из Москвы. Логично, что у любого популярного продукта сразу начинают плодитьяся конкуренты. Призме в этом плане повезло больше всех — благодаря стечению некоторых обстоятельств, основным конкурентом призме стали Mail.ru Group, которые почти сразу выпустил аж 2 похожих продукта со схожими функциями: Vinci (от команды vk.com) и Artisto (от команды my.com).



А лично мне стало интересно посмотреть на эти «клоны» изнутри. Зачем мне всё это и к каким выводам я пришёл — об это я рассказал на roem.ru, повторяться не вижу смысла. На Хабре же я бы хотел поделиться техникой детального анализа приложений для iOS на примере Prisma.

Что нам предстоит? Во-первых, мы узнаем, что есть приложение для iOS и из чего оно состоит, какую информацию можно оттуда извлечь. Во-вторых, я расскажу как снифать траффик client-server приложений, даже если их авторы этого очень сильно не хотят. По факту я не расскажу вам ничего нового, я не придумал никакого ноу-хау, это просто вектор известных техник и умений на приложения. Но будет интересно. Погнали.

Пуск.
37 секунд полета… бабах!
10 лет и 7 миллиардов долларов, потраченных на разработку.
Четыре полуторатонных спутника научной программы Cluster (изучение взаимодействия солнечного излучения с магнитным полем Земли) и ракета носитель Ariane 5 превратились в «конфети» 4 июня 1996 года.
А вину свалили на программистов.



Предыдущая модель — ракета Ariane 4 — успешно запускалась более 100 раз. Что пошло не так?

Чтобы штурмовать небеса, нужно хорошо знать язык Ада.