Отладка *

Мало кто знает, что в ядре Linux есть необычные и весьма полезные инструменты для отладки и тестирования. В этой небольшой статье я хочу поделиться описанием трассировщика ввода-вывода.

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

В качестве группы тестирования интеграции разрабатываемых продуктов мы обязаны не снижать скорость введения нового, обеспечивая в то же время контроль качества и быструю обратную связь для разработчиков. Каждая группа разработчиков отвечает за качество поставляемого ею продукта. Нашей задачей является бесперебойная работа с различными техническими группами с упором на сквозную функциональность и координацию деятельности групп. Мы представляем собой небольшую группу специалистов по тестированию интеграции в организации, насчитывающей более 200 разработчиков.

Быстрый ввод новых разработок при необходимости обеспечении требуемого качества создаёт интересные задачи для нашей команды. В настоящей статье мы рассмотрим три такие задачи:

1. Тестирование и мониторинг высокорейтинговых показов (High Impact Title = HIT = хит)
2. A/B-тестирование
3. Глобальный запуск

Писать многопоточные приложения нелегко. Некоторые средства статического анализа кода позволяют помочь разработчикам, давая возможность чётко определить политики поведения потоков и обеспечить автоматическую проверку выполнения этих политик. Благодаря этому появляется возможность отлавливать состояния гонки потоков или их взаимной блокировки. Эта статья описывает инструмент анализа потокобезопасности С++ кода, встроенный в компилятор Clang. Его можно включить с помощью опции командной строки −Wthread−safety. Данный подход широко распространён в компании Google — полученные от его применения преимущества привели к повсеместному добровольному использованию данной технологии различными командами. Вопреки популярному мнению, необходимость в дополнительных аннотациях кода не стала бременем, а наоборот, дала свои плоды выражающиеся в упрощении поддержки и развития кода.

Предисловие

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

Средства статического анализа кода помогают разработчикам определить политики потокобезопасности и проверять их при сборке проекта. Примером таких политик могут быть утверждения «мьютекс mu всегда должен использоваться при доступе к переменной accountBalance» или «метод draw() должен вызываться только из GUI-потока». Формальное определение политик даёт два основных преимущества:

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

Данная статья рассказывает о применении данного подхода в Clang, хотя изначально он был разработан для GCC, однако версия для GCC более не поддерживается. В Clang данная возможность реализована как предупреждение компилятора. В Google на данный момент вся кодовая база C++ компилируется с включенным по умолчанию анализом потокобезопасности.

В данной статье речь пойдёт об опыте автоматизации функционального и нагрузочного тестирования API протокола RTLSCP. Серверная часть системы локального позиционирования RealTrac состоит из основного (core) сервера, который связывается с устройствами по протоколу INCP (InterNanoCom Protocol) и сервера приложений (appserver). Сервер приложений общается с внешними клиентами и основным сервером по протоколу RTLSCP (Real Track Location System Communication Protocol). Клиенты также могут напрямую обращаться к основному серверу по RTLSCP.

Маргарет Гамильтон стоит рядом с написанным ей исходным кодом бортового компьютера «Аполлона»

Лаборатория реактивного движения (Jet Propulsion Laboratory) — научно-исследовательский центр НАСА, ответственный за большинство беспилотных космических кораблей США. Там пишут много кода, и права на ошибку у них намного меньше, чем у обычных программистов.

В JPL пишут на Си, и на их сайте есть документ "JPL Institutional Coding Standard", описывающий жесткие стандарты кодирования внутри организации. Они напоминают правила программирования для встроенных (embedded) систем и систем реального времени, с ограниченными ресурсами. Но многие из правил эти просто принципы хорошего программирования. Ограничение сложности, максимальное упрощение для последующего чтения кода и отладки, отсутствие побочных эффектов. Мы в Хекслете постоянно говорим об этом в вебинарах и, конечно, в самих курсах. Мы считаем очень важным как можно раньше поднимать эти темы, поэтому про функции и побочные эффекты начинаем говорить в самом первом курсе «Основы программирования», который рассчитан на новичков. Это бесплатный курс, кстати, и в нем есть практика на языке JavaScript.

Спасибо хабраюзеру Boletus за важную поправку и дополнение:
В 2006 году Gerard Holzmann с коллективом сформулировал 10 основных правил для JPL в документе «The Power of 10: Rules for Developing Safety-Critical Code». Они вошли в основу нынешнего стандарта, наряду с MISRA C и другими дополнениями. Статья в Википедии.

Вот перевод этого списка.

12345

Всем привет! Сегодня я хочу рассказать об одном своем проекте, который создавался как один из инструментов получения данных для диссертации, и так как на данный момент он свою основную задачу выполнил, я хочу пустить его в GPLv3-плавание — быть может, он будет полезен кому-то еще. Однако перед тем, как отдать швартовы, я решил воспользоваться профилировщиком Intel Vtune Amplifier, чтобы убедиться в том, что мой пакет имитационного моделирования древовидной сети электроснабжения оптимально расходует вычислительные ресурсы компьютера.



Под катом подробности про себя, про проект и про оптимизацию производительности (которую за полчаса удалось повысить более, чем в два раза)

«Инвесторы и аналитики спрашивали нас о том, что мы запланировали на будущее. Нашим настоящим ответом было бы: «У нас вообще нет планов».»
— Пол Грэм, разработчик, инвестор, эссеист.



Сентябрь 2001
Оригинал — The Other Road Ahead
(За перевод спасибо Щекотовой Яне)

Читать первую часть главы.

Подход к делу

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

Если бы мне приходилось ждать год до следующего релиза, я бы большинство таких идей отложил в долгий ящик, по крайней мере, на некоторое время. Дело в том, что, все-таки, идеи приводят к другим идеям. Вы когда-нибудь замечали, что, как только вы садитесь что-то написать, половина воплощенных в работе идей — это те идеи, которые посетили вас в процессе? То же самое происходит и с программами. Работа над реализацией одной идеи дает вам еще больше идей. Поэтому за откладывание вы заплатите не только задержкой в реализации своей идеи, но также и всеми идеями, к которым вы придете на данном этапе. На самом деле, откладывание препятствует появлению новых идей: как только вы начинаете размышлять о каком-то новом функционале, вы вспоминаете про свой «ящик» и думаете: «Но у меня же уже куча фишек для реализации в следующем релизе».

Intro

Вчера закончились впервые организованные Google`ом соревнования по захвату флага — Google Capture The Flag 2016. Соревнования длились двое суток, за время которых нужно было выжать из предлагаемых тасков как можно больше флагов. Формат соревнования — task-based / jeopardy.

Как заявил гугл, задания для этого CTF составляли люди, являющиеся сотрудниками команды безопасности гугла. Поэтому интерес к данным таскам, как и к первому GCTF в целом, был достаточно велик — всего зарегистрировалось ~2500 команд, из которых, однако, только 900 набрали хотя бы 5 очков на решении тасков (опустим ботов и немногочисленные попытки играть нечестно). Принять участие можно было любому желающему, начиная от rookie и любителей безопасности и заканчивая легендами отраслей. Кроме того, можно было участвовать и в одиночку.

Большую часть от 2х суток я ковырял задания категории Mobile. И в этом хабе представлены writeup`ы всех тасков этой категории. Гугл предложил всего 3 задания для Mobile(в других было по 5-6), но от этого они были, возможно, даже более качественными.

Ну ладно, вода закончилась, переходим к сути :)

Для ясности теоретического понимания нет лучшего пути, чем учиться на своих собственных ошибках, на собственном горьком опыте. (Фридрих Энгельс)

Всем привет!

Несколько недель назад мне в линкедине написал коллега и сообщил, что в моем проекте на гитхабе не совсем верно работает хеш-таблица.

Мне прислали тесты и фикс, и действительно создавалась ситуация, где система "зависала". При расследовании проблемы я понял, что допустил несколько ошибок при верификации. На Хабре тема верификации RTL-кода не слишком подробна расписана, поэтому я и решил написать статью.

Из статьи вы узнаете:

• как можно организовать хеш-таблицу на FPGA.
• на чём была построена верификация.
• какие ошибки я допустил (они привели к тому, что бага не была замечена раньше).
• как это всё можно исправить.

Добро пожаловать под кат!

ARM Cortex-M3 — это, пожалуй, самое популярное на сегодняшний день 32-разрядное процессорное ядро для встраиваемых систем. Микроконтроллеры на его базе выпускают десятки производителей. Причина этому — универсальная, хорошо сбалансированная архитектура, а следствие — непрерывно растущая база готовых программных и аппаратных решений.

Ругать Cortex-M3, в общем-то, не за что, но сегодня я предлагаю подробно рассмотреть Cortex-M4F — расширенную версию всеми любимого процессорного ядра. Перенести проект с микроконтроллера на базе Cortex-M3 на кристалл на базе Cortex-M4F довольно просто, а для ряда задач такой переход стоит затраченных усилий.

Под катом краткий обзор современных Cortex'ов, обстоятельное описание блоков и команд, отличающих Cortex-M4F от Cortex-M3, а также сравнение процессорных ядер на реальной задаче — будем измерять частоту мерцания лампы на микроконтроллерах с разными ядрами.

Выбор инструмента

Проблема профилировки рано или поздно встает перед любым проектом, претендующим на роль лучшего в своей области. Какой инструмент выбрать — всегда большой вопрос. Одни инструменты показывают одну часть картины, другие другую. И рано или поздно начинаешь писать свой тул (англ. tool — орудие\инструмент), который отвечает на насущные проблемы именно данного конкретного проекта. Однако время на написание своего «орудия» всегда приходится вычитать из времени отведенного на сам проект.
Поэтому серьезный профайлер написать не получается…

Но как получить все и сразу? (Тут мне почему то вспоминается песня Queen «I want it all»)

Недавно закончился конкурс обратной разработки ZeroNight2015, проводимый «Лабораторией Касперского». Сама организация конкурса, с моей точки зрения, хромала, но статья не об этом. На конкурсе была представлена интересная задача под названием «Смартфон», разбору которой и будет посвящена данная серия статей. Эта статья будет посвящена описанию условия задачи и поиску защитного механизма. Вторая статья затронет оптимизацию скорости работы взламываемой программы посредством внедрения X-кода. В третьей статье будет описан процесс поиска ошибок во внедренном коде с использованием юнит-тестирования.

В IntelliJ Idea возникают cложности с отладкой таких скриптов, так как для отладки groovy IDE использует сборку груви по-умолчанию, с Ivy провайдером для Grape.

Дано: есть устройство, с ARM926E-JS (Cypress FX3) на борту. Устройство находится на другом континенте. Устройство подключено (JTAG+USB+COM) к Linux компу. На комп есть SSH доступ (и больше ничего, только SSH порт).

Проблема: Устройство нужно отлаживать и писать под него код. И делать это, желательно, удобно.

Решение с использованием OpenOCD, GDB и Qt Creator, а так же описание пути к нему, под катом.

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

Естественно, всё это хорошо автоматизировано уже очень давно, но проблемы случаются. Рассмотрим конкретно ИТ-риски в процессе.

Иногда необходимо редактирование стандартных загрузочных образов, а также конфигурирование систем с последующим тиражированием на большое количество плат Raspberry Pi. Для решения подобных задач удобно использовать пакеты qemu-user-static и binfmt-support.

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

Решили мы как-то перевести свой проект на Visual Studio 2015 — там ведь столько захватывающих фич! Вчера вот только решили, а уже сегодня утром я запустил её инсталлятор. Небо было безоблачным, ничто не предвещало беды. Ну что, в самом деле, может пойти не так? Сколько уже этих Visual Studio переставлено — не счесть (я, помнится, ещё 6.0 когда-то ставил). Кто бы мог подумать, что эта тривиальнейшая задача может вылиться в весьма неожиданный забег по граблям длинной почти в целый рабочий день.

Похрустев немного жестким диском, красивый инсталятор показал мне совершенно некрасивое сообщение об ошибке. Вот такое:


Хм. Не поставился значит, Team Explorer и ещё пару минорных пакетов. Ну ок. Закрываем, переустанавливаем. Не помогает. Удаляем студию, перезагружаемся, устанавливаем — та же ошибка. Лезем в Гугл с вопросом об ошибке установки Visual Studio 2015 на этапе инсталляции компонента Team Explorer и понимаем, что проблема это массовая — десятки ссылок с тем же описанием:
1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17

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

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

Введение

В своих статьях о переходе на российский микроконтроллер К1986ВЕ92QI я ни раз рассказывал о генерации звука средствами микроконтроллера. Тогда передо мной стояла задача лишь воспроизвести данные. Для создания этих самих данных, получаемых из MIDI файлов, использовались весьма экзотические методы, например, как в этой статье. Да, подобные методы имеют право на жизнь, если требуется получить данные для воспроизведения пару раз в жизни. Но так как я достаточно часто сталкиваюсь с задачами, когда на контроллере нужно получить достаточно сложный звук, или же звук — лишь дополнительная опция, то задача преобразовывать MIDI файлы такими экзотическими способами, становится весьма нетривиальной. В этой небольшой серии статей я поставил для себя задачу создать (а за одно и подробно рассказать о процессе создания) универсальную программу для преобразования MIDI файлов в приемлемый для микроконтроллера формат, а так же генерирующую все необходимые для микроконтроллера данные инициализации.



Итогом данной статьи станет реализация основного функционала программы: создание массивов нота-длительность, созданного из MIDI файла. Кто заинтересовался — прошу под кат.