В программировании микроконтроллеров регулярно приходится занимаются починкой bug(ов).
При этом все bug(и) уникальные. Поиск причины каждой конкретной осечки это скорее искусство. Починка программ сродни работы детектива.
Есть ли универсальные приемы того как искать причину программных ошибок?
Считаю, что да. Подробности в тексте...
Бывает ситуация, когда вот стоит нормальный, не ветхий дом с жильцами, с работающими коммуникациями. И простоял бы он так еще много лет. Но принято решение проложить новую магистраль и дом ей мешает. Можно снести дом, недалеко построить новый и жильцов туда переселить. А можно переместить в нужное место сам этот дом прямо вместе с жильцами и тараканами.
Такая аналогия приходит на ум после принятия решения о переходе с платформы Windows на пока единственную сертифицированную альтернативу – ОС Астра Линукс. Как жильцы гипотетического дома не могли отменить решение о магистрали, так и мы не можем отменить это решение. Придется переходить. Однако легко сказать «перейти». Когда я познакомился с IBM-PC/XT, какой-нибудь Торвальдс еще школу не кончил. За эти годы (чего уж там годы - десятилетия) появилось много привычек, приемов, навыков. Жалко все это оставлять ради принудительного перехода в другую среду. И приходит мысль – попытаться переехать, так сказать, всем домом, а не строить новый.
Я программист, а то что я еще и реверсер - ну... так совпало. И как любому из людей занимающимся реверсом мне всегда не хватает функционала отладчика. Постоянно приходится допиливать под конкретную задачу какие-то утилитарные вещи и однажды...
Однажды я решил - хватит, каждый раз пилить новое достаточно утомительно, а что если взять и объединить все наработки в один инструмент и пользоваться именно им!
Это будет скорее рекламный пост - но не спешите минусовать, возможности утилиты, о которой пойдет речь, а называется она Process Memory Map, весьма обширны, и возможно вам понравится :)
Итак - что это такое? Она похожа на всем известный инструмент от Марка Руссиновича VMMap (которая кстати частично основана на коде Джефри Рихтера), её задача проанализировать сторонний процесс и вытащить из него максимум данных, о которых она знает.
Когда на нашей рабочей системе происходит какая-либо ошибка, нам хочется, чтобы логи содержали всю необходимую информацию о том, из-за чего она произошла. На достаточно сложных системах это приводит к сбору большого количества данных: какие этапы обработки были выполнены, с какими аргументами вызывались те или иные методы, что вернули запросы к внешним системам и т. д. Проблема заключается в том, что эту информацию нам приходится собирать даже в случае, если никакой ошибки не произошло. А это приводит к росту объёма наших логов, за который нам приходится платить деньги.
Уровни логирования (error, warning, information, ...) здесь помогают мало. Обычно для приложения выставляется некий целевой уровень (например, information). Это означает, что все записи с уровнем выше или равным данному попадают в логи, а менее значимые выбрасываются. Но в тот момент, когда происходит ошибка, для нас наибольший интерес представляют именно записи debug-уровня, которые обычно и выбрасываются. Хорошо, если ошибка встречается довольно часто. В это случае можно временно опустить целевой уровень логирования системы, собрать информацию об ошибке, а потом вернуть уровень назад. Таким образом объём собираемых логов возрастёт только временно. Если же ошибка встречается достаточно редко, такой подход хоть и возможен, но не очень удобен, поскольку приводит к значительному росту объёма логов.
Можно ли как-то улучшить сложившуюся ситуацию? Я думаю, что можно. Сразу оговорюсь, что в этой статье я предлагаю не готовое решение, а скорее пожелание к существующим системам логирования, поскольку реализация этого подхода по-видимому потребует внесения изменений в их исходный код.
Всем привет! Сегодня я хочу рассказать о Mock Service Worker — технологии, которая позволяет эмулировать поведение бэкенда в ситуациях, когда по каким-то причинам невозможно использовать реальный бэкенд для полноценной разработки фронтенда, а также когда необходимо изолированно протестировать различные пользовательские сценарии. Тем более, что совсем недавно вышла новая мажорная версия библиотеки msw, и в ней достаточно много важных обновлений.
Введение
Вы когда-нибудь участвовали в проекте разработки ПО, в котором отсутствовали жизненно необходимые меры по обеспечению качества? Вы в этом не одиноки. Такое случается в потрясающе огромном проценте компаний и проектов. Даже если компании знают о существовании такого понятия, как QA, и что его нужно выполнять, все усилия обычно приводят лишь к большому спринту QA прямо перед релизом. Это стрессовый период, в который мы пытаемся заставить ПО хотя бы немного работать. Разумеется, весь этот хаос повторяется на следующем цикле релиза без малейших улучшений.
Чему нас учат в вузах
Проблема в том, что при изучении computer science вас не учат, как обеспечить стандарты качества ПО. Основную часть времени тратят на изучение алгоритмов, принципов работы компьютера, историю каких-то языков и концепций и так далее. Кроме того, по крайней мере, в моей учёбе, был семестр, посвящённый методикам управления проектами и Scrum. Всё это замечательно, но тут совершенно отсутствует QA. Пренебрежение QA — это огромная потеря, потому что больше 90% всех студентов после завершения учёбы работает в контексте компаний. Они должны будут выпускать ПО вовремя и без багов.
Этой частью завершается серия статей, рассказывающих о разработке и тестировании сумматора с AXI-Stream интерфейсами. Мы покажем, как можно улучшить тестовое окружение за счет добавления возможности его настройки без повторной перекомпиляции исходников. Также мы модифицируем драйверы и мониторы AXI-Stream интерфейса, чтобы их можно было повторно использовать в других окружениях и проектах.
Чем заменить санкционные микроконтроллеры STM, Kinetis и другие, особенно для ответственных и безопасных приложений? - На наши российские, конечно, если такие найти. Но ведь есть еще и микроконтроллеры из Китая, которые благодаря дружбе наших стран можно использовать вместо чипов ушедших с рынка иностранных компаний.
Много кто знает про китайские клоны STM32, но помимо этого китайские производители также предлагают микроконтроллеры для ответственных и безопасных приложений. Проблема в том, что пока мало кто знает про эти современные и уникальные чипы.
В статье можно прочитать про безопасные микроконтроллеры Flagchip, которые предназначены для разработки надежных и безопасных электронных блоков современных автомобилей и способны заменить популярные иностранные микроконтроллеры.
В предыдущей статье мы познакомились с основами работы AXI-Stream протокола и модифицировали наш сумматор, чтобы он был совместим с этим интерфейсом. Также было отмечено, что из-за увеличения сложности сумматора встает проблема в его тестировании. Напрямую генерировать все возможные входные воздействия достаточно сложно из-за большого количества их различных вариантов. Еще утомительней каждый раз вручную просматривать временные диаграммы в поисках ошибок. Нам нужен другой подход, и именно это мы будем обсуждать в этой статье.
При разработке и последующем производстве электроники неизбежно встаёт вопрос проверки собранных изделий. Если компания небольшая, а производство мелкосерийное, то в жертву рутине можно принести какого-нибудь начинающего специалиста, либо самого разработчика. Как правило, требуется проверить несколько напряжении, пару цифровых интерфейсов, световую, звуковую индикацию и т. п. Но предварительно в контроллер необходимо записать программу. В мелкой серии длительность тестирования особой роли не играет. Трудности начинаются, когда каждый месяц производится десяток тысяч изделий.
Вопрос в том, что прошивка устройства внешним программатором – это отдельная технологическая операция, требующая времени и оплаты. Столкнувшись с такой постановкой задачи, пришлось некоторое время повозиться, чтобы реализовать автономный SWD программатор в составе технологической оснастки. Все операции по проверке собранных печатных плат, включая программирование, объединяются в тестовую последовательность, а полное время проверок сводится к возможному минимуму. Надеюсь, что представленная информация облегчит дело тем самураям, которые решат пройти по схожему пути.
Несколько лет назад я отказался от всего и полностью сосредоточился на WebAssembly. В то время Rust имел наилучшую поддержку компиляции в WebAssembly, а самые полнофункциональные среды исполнения WebAssembly были основаны на Rust. Rust был лучшим из вариантов. С места в карьер я нетерпеливо начал разбираться, чем же вызван такой ажиотаж.
С тех пор мы с потрясающими разработчиками создали Wick, — фреймворк приложений и среду исполнения, использующие в качестве системы основного модуля WebAssembly.
Спустя три года, выполнив несколько развёртываний в продакшен, написав электронную книгу и выпустив примерно сто пакетов на crates.io, я решил, что настало время поделиться своими мыслями о Rust.
Вторая статья из цикла, посвященного проектированию с использованием стандартного интерфейса AXI-Stream, а также отладке и документации проектов.
В данном цикле статей будет представлен процесс разработки и тестирования RTLмодулей на языке Verilog. В качестве примера будет рассмотрен целочисленный
сумматор с AXI-Stream интерфейсами. Мы разберем некоторые приемы и паттерны,
часто используемые при проектировании цифровых устройств. Также мы покажем
типовую структуру тестового окружения для проверки RTL-модулей.
Описанное нами окружение будет состоять из отдельных компонентов, у каждого из
которых будет своя конкретная задача. При правильном подходе к разработке этих
компонентов их можно будет повторно использовать в других тестовых окружениях.
Всем привет! Меня зовут Соня Гусева, я фронтенд-разработчик в Яндекс Практикуме (или фронтенд-капибара). Вместе с командой мы развиваем платформу practicum.yandex.ru. Например, сделали поиск по пройденным материалам — тот самый, где «найдётся всё». И тёмную тему — для комфортной учёбы даже ночью.
Практикум появился в 2019 году и с тех пор растёт. В какой-то момент нам стало сложно погружать новичков в проект. Дело в том, что стиль кода всё время развивался, но правила оставались на уровне устных договорённостей. В итоге приходили новые тиммейты, видели легаси и более свежий код — и не понимали, какой написан правильно и почему они разные. Как следствие, код-ревью растягивалось, и тестирование проходило в разы сложнее. Люди чувствовали себя неуютно в таких процессах.
Нас спас единый гайд по стилю кода — документ, в котором мы закрепили правила по оформлению кода для всей команды. В этой статье я расскажу, от каких проблем вас сможет защитить такой гайд, и приведу подробную инструкцию, как его внедрить.
Если вы любите больше смотреть, а не читать, с этой темой я выступила на Frontend meetup, где рассказала подробно о внедрении стиля кода в проекты.
Память — достаточно дефицитный ресурс для многих компьютеров потребительского уровня, поэтому логично создать функцию, ограничивающую объём используемой процессом памяти; и Microsoft действительно реализовала такую функцию. Однако:
Компания её не задокументировала (!)
Её реализация на самом деле не экономит память
Реализация может иметь чрезмерно высокие затраты ресурсов CPU
Эта функция ограничивает рабочий набор процесса (количество памяти, отображённое в адресное пространство процесса) 32 мегабайтами. Прежде чем читать дальше, попробуйте предположить, какое максимальное замедление может вызывать эта функция. То есть если процесс многократно затрагивает больше, чем 32 МБ памяти (допустим 64 МБ памяти), то насколько больше будут занимать эти операции с памятью по сравнению с ситуацией без ограничений рабочего набора? Остановитесь на минуту и запишите своё предположение. Ответ будет ниже в посте.
Вышла новая версия программы для просмотра и анализа логов — Chipmunk v.3. Инструмент был полностью переработан с упором на производительность и переосмыслен с акцентом на простоту и удобство использования. Под капотом очень краткое описание нововведений и возможностей.
Всем привет!
Меня зовут Паша Востриков, я делаю на JS/TS много разного в «Лаборатории Касперского»: фронт, облачные сервисы (Node.js), штуки для коробочной поставки (OnPrem), платформенные компоненты и библиотеки. И, конечно же, Open Source.
Сегодня хотел бы затронуть тему отладки веб-приложений на JavaScript.
Итак, как отлаживаться? Как-как? console.log(1)
Примерно полтора года назад я попросил у своей бывшей компании разрешения поработать над проблемой, влиявшей на возможности отладки нашего проекта: gdbserver не мог отлаживать многопоточные приложения, работающие на архитектуре PowerPC32. Подключение к gdbserver было поломано, и он больше не мог контролировать сессию отладки. Разные люди исследовали эту проблему до меня, и у меня уже был неплохой фундамент, но мы всё равно не знали точно, в каком конкретно программном компоненте таится проблема: это мог быть тулчейн, gdbserver, ядро Linux или собственные патчи, которые мы устанавливали поверх дерева ядра. От нахождения первопричины мы находились довольно далеко.
Привет, Хабр! Меня зовут Александр Калинин, я занимаюсь разработкой средств обеспечения безопасности контейнерных сред в МТС RED, дочерней компании МТС в сфере кибербезопасности. Сегодня расскажу о том, как я обнаружил в отладчике WinDbg уязвимость, которая позволяет запускать произвольный вредоносный код на хосте разработчика и подменять библиотеки. Также поговорим о реакции Microsoft на мой репорт.
