В программировании микроконтроллеров регулярно приходится занимаются починкой bug(ов).
При этом все bug(и) уникальные. Поиск причины каждой конкретной осечки это скорее искусство. Починка программ сродни работы детектива.
Есть ли универсальные приемы того как искать причину программных ошибок?
Считаю, что да. Подробности в тексте...
В этом тексте я написал инструкцию того как настроить логический анализатор Saleae производить автоматический синтаксический разбор трафика на шине I2S.
В разных областях деятельности приходится строить графики. Построить график на компьютере можно десятками если не сотнями способов. В этот тексте я показал как строить графики при помощи интерпретируемого языка программирования Python.
Существует ряд ситуаций, когда это имеет смысл. От полного контроля памяти, до вынужденной необходимости. К примеру, одна из возможных ситуаций:
1. Мы используем alignment аллокаторы.
2. Мы перегружаем какой-то класс и данные от нашей 3rd зависимости.
3. 3rd зависимость не использует alignment аллокаторы.
К старту курса по разработке на Java делимся руководством о том, как отлаживать коллекции Java на продакшене с платформой Lightrun и избегать при этом неприятностей с методом list.toArray(). За подробностями приглашаем под кат.
В данном курсе планируется разобрать основные особенности программирования на самой простой реализации assembler – TASM. Этих знаний лично мне вполне хватило, чтобы на отлично сдать ЭВМ в институте и закончить все лабораторные работы. Во многих уроках будет домашние задание по их мотивам.
Для начала давайте установим наш старенький компилятор.
Ссылка
Знаете ли вы, как работает такая серьезная программа оценки производительности, как Intel VTune Amplifier? Не в смысле интерфейса с пользователем и разных возможностей, а на какой аппаратной поддержке она основана?
Я попытался найти об этом информацию, но как-то разработчики этой программы не делятся с пользователями объяснениями, как именно они получают данные о пользовательской программе. Вероятно, никаких секретных команд и способов там нет. Все основано на сигналах прерываний и установке аппаратных и программных контрольных точек (которые тоже вызывают прерывания). Ну и, конечно, на чтении «телеметрии» самого процессора.
Я не рассматриваю здесь интерпретируемые языки типа Питона. Ясно, что интерпретатор и безо всяких сигналов прерываний легко может собирать статистику при выполнении программы. А вот все остальное, кроме случаев вставки в код специальных вызовов, так или иначе, требует прерываний. Ну, или, например, виртуальной машины, которая тоже требует прерываний.
При этом близкое к идеальному с точки зрения накладных расходов профилирование кода получается, когда используют метод Монте-Карло, который позволяет оценить распределение нагрузки с точностью до периода таймерного прерывания.
Т.е. достаточно поставить обработчик на системный таймер и извлекать из автоматически запоминаемого контекста указатель текущей команды RIP (EIP). Затем, имея адреса подпрограмм, легко определить, какая именно подпрограмма работала в момент прерывания, и статистически учитывать это в профиле выполняемого кода. Поиск подпрограммы по адресу RIP процесс, конечно, тоже не мгновенный и не бесплатный, но его можно отложить, а в реальном времени лишь запоминать в памяти очередное значение RIP.
Никакой специальной аппаратной поддержки в данном случае не требуется и для типового кода метод дает хорошие результаты даже для периодичности таймера порядка мс. Но программисты все равно недовольны; «для программ, обрабатывающих тысячи событий в секунду, требуется сильное уменьшение периода, а это и дает большие накладные расходы, и портит результат. Кроме этого, такой метод часто неприменим для профилирования низкоуровневого кода — тех же обработчиков прерываний, процедур планировщика ОС и т.п.»
Утечка горутин в Go происходит, когда горутина продолжает существовать и потреблять ресурсы, даже если она больше не выполняет полезной работы или не может завершиться. Это может произойти по разным причинам.
Мы рассмотрим 3 примера из которых: 2 будут на каналах, 1 с использованием mutex.
Все мы сталкиваемся с багами, фиксим их, и по новой тестируем наш код.
Давайте попробуем сделать работу с багами чуть проще и прозрачнее. Разберем как можно их находить и с ними справляться. Разберем: IDE, изоляции, консоль браузера, console.log(), Try-Catch и т.д.
Два года назад взялся писать программу, что помогает выставлять счета за аренду ковров. Прежде бухгалтер держал текст договоров в Word, расписание в Excel, а три дня каждого месяца убивал на подсчеты. Теперь программа сама рассчитает суммы и загрузит счета в 1С.
Компания такая не одна: защищу программу - продам ключи.
Защита программы - трудное дело. Исследую защитные алгоритмы на практике: вытащу из готовых программ, а чтобы никому не вредить, исследую программы, что специально написаны для взлома - crackme или keygenme.
Жребий пал на q_keygenme_1.0 by quetz.
На работе предложили прочитать доклад. Вуаля! Далее расскажу:
✓ Что такое кодревью?
✓ Зачем нужен?
✓ Что проверяем?
✓ Типовые проблемы & решения
✓ БОНУС!!! Результаты опроса: «Как вы делаете кодревью?»
ViewController — это один из компонентов, где обычно происходит утечка памяти, поскольку именно он чаще всего используется для хранения множества частей кода вместе. Одна ошибка, и в итоге вы получаете утечку.
Apple предлагает отличный инструмент для отладки утечек памяти. Часто для этого используется метод print в deinit.
Ошибки есть в каждом коде. Мы перевели гайд разработчика Айо Исайя, в котором он рассказывает о системе ошибок и о том, как их устранять.
Очередной «смешной случай из жизни» заставил немного понервничать.
Сопровождаемая нами программа имеет два окна: основное графическое и вспомогательное консольное. Свернутое при запуске консольное окно, как правило, нужно только при крахе системы, в нем выдаются стандартные сообщения об ошибках, и можно даже вызвать интерактивный отладчик, с помощью которого попытаться определить причину падения.
Однако при эксплуатации получилось не очень удобно. Дело в том, что если при крахе приложение снять, то, естественно, графическое окно исчезает, и пользователю, по крайней мере, сразу видно, что вся система рухнула. Правда и информация о крахе системы так же исчезает с одновременным закрытием и консольного окна. А вот если управление перехватывает отладчик в консольном (свернутом по умолчанию) окне, то графическое изображение на экране «замораживается» и при беглом взгляде может показаться, что все еще продолжает работать. Бывали случаи введения пользователя такой картиной в заблуждение. В конце концов, был найден компромисс: при исключении программа все-таки снимается, но вся информация, выдаваемая в консольном окне, дублируется еще и в файл протокола.
В нашей системе программирования так легко сделать, поскольку в системной библиотеке перед каждой выдачей очередного байта стандартного сообщения в стандартную консоль, идет проверка: а есть ли подпрограмма пользователя, которую нужно каждый раз вызывать перед очередной выдачей байта? Если есть – она вызывается с единственным параметром, этим самым байтом.
Идеальный способ отлаживать и отслеживать приложения — хорошо определённые, информативные и удобно структурированные логи. Они являются необходимым компонентом любого — малого, среднего или крупного — проекта на любом языке программирования, не только на Python. Не используйте print() или корневой логгер по умолчанию, вместо этого настройте логирование на уровне проекта. К старту нового потока курса по Data Science, мы перевели статью, автор которой решил поделиться своим шаблоном для логирования. Не лишним будет сказать, что этот шаблон пришёлся по душе многим специалистам — от дата-сайентистов профессионалов и до разработчиков ПО разного уровня.
