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

Итак...

Какое-то время назад я писал код прошивки для грабберов 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 выяснили причину проблемы и справились с ней.

Скачать файл с кодом и данные можно в оригинале поста в моем блоге

Картинка к вебинару и посту взята не просто так: в определенном смысле символьное ядро Wolfram Language можно сравнить с Таносом — если бы его мощь была бы направлена в правильное русло, он мог бы стать самым мощным и полезным «добряком». Так же и с символьным ядром Wolfram — его чудовищную мощь нужно правильно использовать, а если это делать не так, оно может стать настоящим «злом», замедляющим все очень сильно. Начинающие разработчики не знают многих важнейших парадигм, идей и принципов языка Wolfram Language, пишут код, который на самом деле дико неэффективен и после этого разочаровываются, хотя тут нет вины Wolfram Language. Эту ситуацию призвана исправить эта статья.

Мне довелось работать с Wolfram Language начиная с (уже довольно далекого) 2005 года (тогда еще была версия Mathematica 5.2, сейчас уже 12-я). За эти почти 15 лет произошло очень много: добавились тысячи новых встроенных функций и областей, в которых они работают (машинное обучение, точная геометрия, работа с аудио, работа в вебе, облачные возможности, глубокая поддержка единиц измерения, интеграция с базами данных Wolfram|Alpha, географические вычисления, поддержка работы с CUDA, Python, распараллеливание операций и многое многое другое), появились новые сервисы — облако Wolfram Cloud, широко известная система вычислительных значeний Wolfram|Alpha, репозиторий функций, репозиторий нейросетей и пр.

Делая пере-реализацию QInst на LLVM, я столкнулся с такой проблемой: QEMU в режиме эмуляции одного процесса естественным образом перехватывает все «гостевые» системные вызовы. В итоге плагин инструментации имеет единую точку входа для их предобработки, где можно по номерам SYS_* и значениям аргументов принимать решения. Это довольно удобно. Проблема в том, что все системные вызовы делает, в основном, libc и, переписывая код статически, мы просто до этой части в большинстве случаев не доберёмся. Конечно, можно было бы использовать ptrace, который как раз предназначен и для этого в том числе. Но тогда не уверен, что получилось бы обойтись без отдельного процесса, а семантика QInst предполагала тривиальный «синхронный» перехват — пришлось бы как-то инжектить вызов обработчика, а это сильно сложнее привычного LD_PRELOAD. Можно оборачивать каждый системный вызов — но это, как минимум, неудобно (к тому же, можем что-нибудь пропустить, ведь в этом случае мы перехватываем на самом не системные вызовы, а их конкретные обёртки).

Под катом — решение, не привязанное к LLVM, но заточенное под Linux на x86_64 (но адаптируемое для Linux на других архитектурах).

Примечание: в этой статье не представлено универсального готового решения — оно лишь подходит для достаточно широкого списка случаев. Зато эту статью можно считать обзорно-пятничной: интересная (надеюсь) новая (для большинства?) информация, щепотка брутфорс-программирования и рабочие примеры. И пусть нашу пятницу не омрачает даже тот факт, что сегодня четверг!

Есть у меня один Python-скрипт с расчётами. Там был цикл примерно на 2000 итераций, каждая из которых считалась несколько минут.

И решил я, чтобы ловчее отлаживать тот скрипт, выводить график кой-каких метрик от номера итерации. И как посчитается очередная итерация, так оный график и обновлять.

Проще всего проделать это с помощью bokeh. Точнее, с помощью bokeh-сервера для отрисовки графиков. Как — сейчас расскажу.