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


Алексей Миловидов (o6CuFl2Q) расскажет о самых нелепых, обескураживающих и безнадёжных проблемах из его опыта разработки и поддержки ClickHouse. Посмотрим, как их приходилось отлаживать и какие меры принимать разработчикам с самого начала, чтобы проблем было меньше.

Приветствую,

На днях товарищи из Hex-Rays анонсировали новую IDA Home, которая как IDA Starter, только под одну конкретную платформу (против более чем 20-ти), с локальным отладчиком и поддержкой x64, скриптингом на Python и стоит 365$ в год (против $979). Далее был запущен конкурс на лучший рисунок логотип для новой IDA, за который автор лучшей работы получит Home-версию бесплатно.

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

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

А туда ты не ходил так давно, что раздало файл с логами аж до 100 мб. или до 500 мб. Черт! А может и до 10 Гб (*). И лежат драгоценные улики где-то там среди 10 737 418 240 байтов, что надо срочно пробежать, дабы выяснить, что ж вообще происходит, меж тем как кофе уже остывает.

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

Знакомо?

В общем все мы так или иначе сталкиваемся с необходимостью анализа «следов жизнедеятельности» наших творений и хорошо если файл весит пару Мб, потому как открыть лог в 1 Гб блокнотом, да ещё и попытаться поиск сделать — занятие весьма сомнительное.

Под катом поведаю об одном инструменте, не имеющим лимитов (**) по размерности открываемых файлов, зато обладающим весьма шустрым поиском.

А ещё приглашу к разработке присоединиться.

И да, будет много интересных картинок.

Долго думал, можно ли переопубликовывать статью на Хабре, проштудировал правила, вроде как сейчас это не возбраняется. Если ошибся — исправлюсь :)

Итак...

Какое-то время назад я писал код прошивки для грабберов Epiphan линейки AV.io:

• AV.io HD — наш пилот, на котором многое было отлажено и сформирована архитектура
• AV.io SDI — закрепляем позиции
• AV.io 4K — уже новое железо и новые подходы, теперь запускаемся практически мгновенно
• KVM2USB 3.0 — глубокое переосмысление AV.io HD. По сути, благодаря заложенному потенциалу для модернизации в базовую модель, практически без модификации железа, чисто софтом смогли сделать новый продукт.

Там был задействован Cypress FX3, а SDK был построен поверх ThreadX. В качестве JTAG отладчика можно использовать Olimex ARM-USB-OCD-H в связке с OpenOCD. К сожалению, OpenOCD ничего не знает про треды в RTOS и, хотя, базовая поддержка присутствует в коде, конкретно для нашего процессора использовалась схема стекинга регистров, которая отличалась от того, что было уже реализовано. Пришлось разбираться и дорабатывать. Профиты от использования JTAG для разработки трудно переоценить, как минимум в случае распределённой работы.

Итак, время идёт. Теперь очередь за FPGA от Xilinx и его софтовым процессором MicroBlaze, где можно запустить портированый FreeRTOS версии 10.x. Но проблема ровно такая же: поддержки тредов в отладчике нет!

В некотором 2017 году, во время отладки в VS, производительность в проекте падала на ~80%, превращая игру в сборник различных ассинхронных кадров. Виновником торжества стала функция SetThreadName внутри пула.

Недавно вышла новая версия Windows Terminal. Всё бы ничего, но работоспособность её скроллбара оставляла желать лучшего. Поэтому настало время немного потыкать в него палкой и сыграть на бубне.

Как говорилось в одном анекдоте, «Салат Фибоначчи готовится из того, что осталось от вчерашнего и позавчерашнего салата Фибоначчи». Вот и сейчас попробуем на практике применить перехват системных вызовов через seccomp для целей ускорения минимизации исходника при сохранении инварианта. До кучи, проблема будет решаться посредством инжектирования форк-сервера, очень похожего на тот, который используется в American Fuzzy Lop. И всё это будет управляться из Java-кода.

Для тех, кто уже настроился почитать про модификацию чужих процессов через ptrace прямо из Java — нет, всё не настолько сурово, я просто на ходу собираю .so из .c и вгружаю через LD_PRELOAD.

Для тех же, кто уже подумал «Знаю я этот AFL — компилятор придётся патчить и пересобирать!», скажу, что в том и смысл использования seccomp: мы на ходу поймаем момент, когда произойдёт первое обращение ко входному файлу.

Есть конечно и ложка дёгтя: компилятор должен быть однопоточным, однопроцессным и на Линуксе, но в реально-тестовой задаче минимизации примера бага в компиляторе из OpenModelica удалось добиться ускорения раз в 5.

Как найти зловреда (нет) с WinDbg

Вступление

В этой статье я покажу, как, например, с помощью WinDbg найти, какой такой зловред (или нет) заменил адрес вызова системной функции в DLL, подгружаемым каким-нибудь приложением. Так я, к примеру, искал почему не загружается модуль защиты в конфигурацию 1С.
Для демонстрации нам понадобится приложение, которое загружает пару DLL: одну из них назовём victim (жертва), другую — хищник injector. Последнняя внедряется в жертву, заменяя вызов системной функции (для простоты возьмём Sleep), и будет вызывать AV при определённых условиях (что понадобится в следующей статье).

Т.к. приложения, написанные на Delphi, "не падают" в core-dump из-за необработаных исключений, то наше главное приложение (DLLInjectionDemo) написано на С, линковано ранним связыванием с DLL-жертвой, а для простоты воспроизведения ситуации, будет загружать DLL-injector, переданную в опциях при запуске, и вызывать в ней метод, который навредит жертве. Конкретно для этой статьи нам подошло бы приложение, написанное на любом языке программирования, но убьём двух зайцев сразу.

Исходные коды приложений написаны на C и Delphi 10.3 Rio Community Edition, и компилируются MinGW и Delphi, как для Win32, так и для Win64 (а также FPC в Lazarus-е).

Итак компилируем обе DLL и главное приложение

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

Как этого можно избежать?

Docker-in-Docker представляет собой виртуализированную среду Docker-демон, запущенную в самом контейнере для сборки образов контейнера. Основной целью создания Docker-in-Docker была помощь в разработке самого Docker. Многие люди используют его для запуска Jenkins CI. Поначалу это кажется нормальным, но затем возникают проблемы, которых можно избежать, установив Docker в контейнер Jenkins CI. В этой статье рассказывается, как это сделать. Если вас интересует итоговое решение без подробностей, просто прочитайте последний раздел статьи «Решение проблемы».

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

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

• logcat – инструмент для просмотра логов приложения, в том числе и исключений при краше. Его можно использовать как в Android Studio, так и в терминале, через adb;
• Android profiler – мощный инструмент, который позволяет просматривать все сетевые запросы, загрузку процессора, памяти и батареи.

Также существует множество сторонних решений, позволяющих просматривать сетевой трафик, базы данных, shared preferences и др.
У всех этих инструментов есть преимущества и недостатки. К их минусам можно отнести следующее:

• множество зависимостей различных инструментов;
• сложность использования – как правило, все инструменты ориентированы на разработчиков и неудобны другим участникам команды, например, тестировщикам, аналитикам или back-end разработчикам. Обычно последним приходится дергать android-разработчиков, чтобы просмотреть какие-либо логи;
• обязательное подключение телефона к компьютеру, например, через usb-кабель.

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

Android Remote Debugger

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

• Logging — просмотр логов приложения, включая краши;
• Database — просмотр и редактирование записей в базе данных;
• Network — просмотр всех сетевых запросов и ответов в удобном формате;
• SharedPreferences – просмотр и редактирование данных SharedPreferences.

Зачем и для чего

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

В сети не много информации о появившемся несколько лет назад GDB сервере EBlink. Этим постом постараюсь исправить ситуацию.

EBlink поддерживает большинство моделей микроконтроллеров STM32 (серии F0, F1, F2, F3, F4, F7, H7, L0, L1, L4, G0 и G4), а также EFR32.

Он интересен тем что поддерживает скрипты на Си-подобном языке Squirrel которые участвуют в процессе прошивки и отладки микроконтроллеров. Это позволяет отредактировав скрипты добавить новые микроконтроллеры или изменить работу с существующими не вмешиваясь в исходный код EBlink. Могу предположить таким образом возможно добавить микроконтроллеры с ядром ARM Cormex-M других производителей, например компании Миландр но это не было проверено.

Группа строений кампуса Microsoft от №16 до №18 многие годы служила домом для команды разработчиков Microsoft Office. Когда они переехали в строение №37, все машины в старой лаборатории выключили и перевели в новую лабораторию здания 37.

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

И они почти дождались до конца цикла поддержки продукта, но увы – была обнаружена проблема с безопасностью, влиявшая на разные версии Microsoft Office, включая и Office 97, поэтому машины проекта нужно было включить и провести через все этапы сборки программы. Команда надеялась, что это будет быстрый и успешный процесс.

В эти чудесные январские дни всех нас, конечно, волнует вопрос минимизации исходного кода с сохранением инварианта. В смысле, не волнует?!? Зря… Вот упал у вас компилятор, а программа гигантская — как-то неудобно такое разработчикам слать. И тут начинается веселье: а если вот это выкинуть? О, не падает — ладно, оставляем, а если это? — всё ещё падает, и это, и это, и то… Ой, я компилятор на старых исходниках запускал.

В то же время, автоматизация поиска багов — дело-то житейское: git bisect, llvm-bugpoint, creduce,… В статье я опишу yet another способ решения проблемы упрощения тестового случая, более-менее универсальный по отношению к языку программирования, и покажу некоторые примеры использования.

Привет, Хабр! Представляю Вашему вниманию перевод статьи «6 Tips To A Successful Code Review».

Сode review во все времена являлся основополагающей практикой, отвечающей за создание чистого и поддерживаемого кода.

Частенько разработчики пренебрегают и недооценивают code review по причинам, которые кажутся в тот момент объективно правильными.

Давайте сегодня сформулируем 6 советов, чтобы провести качественный и плодотворный code review.

ghostinushanka, молотив по кнопкам в течение предыдущих 20 минут, как если бы от этого зависела его жизнь, поворачивается ко мне с полу-диким выражением в глазах и хитрой ухмылкой — "Чувак, я кажется понял."

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

Немного озадаченный и уставший, я изменяю sed выражение, над которым мы какое-то время уже работали, сохраняю файл и запускаю systemctl varnish reload. Сообщение об ошибке исчезло...

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

Продолжим цикл статей об автоматизации тестирования Embedded систем. В этой статье будет рассказано как можно быстро и относительно просто интегрировать возможность управления питанием тестируемого устройства из тестового скрипта а так же получить возможность имитировать нажатия механических кнопок по команде из тестового скрипта.

Итак, что имеем:

1. Десятки Embedded устройств в которых нужно проводить тестирование новой версии FirmWare (если быть точнее — ежедневная сборка прошивки)
2. В виду особенностей процедуры загрузки FW может потребоваться необходимость сбросить питание (т.н. режим загрузки прошивки в режиме Power On Capture)
3. Хотелось бы в некоторые конкретные моменты времени по ходу выполнения тестового скрипта имитировать нажатия на механические кнопки размещенные на отладочной плате Embededed системы
   

Когда я только начинал работать с Express и пытался разобраться с тем, как обрабатывать ошибки, мне пришлось нелегко. Возникало такое ощущение, будто никто не писал о том, что мне было нужно. В итоге мне пришлось самому искать ответы на мои вопросы. Сегодня я хочу рассказать всё, что знаю об обработке ошибок в Express-приложениях. Начнём с синхронных ошибок.

Недавно в Redash приступили к смене одной системы выполнения задач на другую. А именно — они начали переход с Celery на RQ. На первом этапе на новую платформу перевели лишь те задания, которые не выполняют запросы напрямую. Среди таких заданий — отправка электронных писем, выяснение того, какие запросы должны быть обновлены, запись пользовательских событий и другие вспомогательные задачи.



После развёртывания всего этого было замечено, что RQ-воркеры требуют гораздо больше вычислительных ресурсов для решения того же объёма задач, который раньше решали средствами Celery.

Материал, перевод которого мы сегодня публикуем, посвящён рассказу о том, как в Redash выяснили причину проблемы и справились с ней.