Отладка *

Понимайте свою программу без ущерба для производительности

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

Python предоставляет довольно мощный и гибкий встроенный модуль logging со множеством возможностей. В этой статье я хочу поделиться восемью продвинутыми возможностями, которые будут полезны при разработке ПО.

Так получилось, что в последние несколько лет я сшиваю Франкенштейнов, а не ваяю милые фарфоровые статуэтки пастушек и трубочистов. Я создаю решения на базе Magento 2. Это значит, что исходный материал у меня — мечта любого археолога. Культурный слой со следами различных "эпох" и "цивилизаций". По нему можно изучать развитие программистской мысли в PHP/JS сообществах в течение последнего десятилетия.

И это только базис, а надстройка — сторонние модули, которые нужно интегрировать вовнутрь. Вот тут уже можно столкнуться с проявлениями внеземного разума. Некоторые модули созданы развитыми существами, очень похожими по мышлению на создателей базиса, но попадаются такие, что хочется приобнять автора за плечо, проникновенно заглянуть ему в глаза и по-дружески так спросить: "Ты с какой планеты, родной?"

Сшить Франкенштейна из такого материала помогает отладчик (debugger). Ниже идёт мой персональный топ приёмов кодирования, которые способны усложнить жизнь любому, кто, как и я, ежедневно использует отладчик в своей жизни. Он небольшой, на четыре позиции, но каждый раз, когда я сталкиваюсь с подобным при отладке — я печалюсь. Может быть мой пост уменьшит количество скорбей в мире, а может и нет. Я, по крайней мере, попытаюсь.

Недавно при написании библиотеки к ESP-32 возникла необходимость ловить дедлоки, которые возникали иногда из-за моей криворукости, что породило необходимость покупки платы-отладчика с интерфейсом JTAG. Что из этого вышло — читайте под катом.

1. Выполнение каких действий вы ожидаете от своей программы?
2. Почему вы ожидаете этого от программы?
3. Делает ли программа то, что вы от неё ожидаете?

Вступление

Вступление

1. iOS 7.0-7.0.4 устройство с evasi0n jailbreak и компьютер с Mac OS X 10.9.4, установленным XCode 5.1.1 и МаchOView 2.4 (скорее всего для других версий тоже будет работать, но я не пробовал)
2. некоторый опыт в отладке third-party приложения для iOS, ну и желательно знать что такое ASLR и понимать зачем его отключать

Disclaimer: "чукча не писатель, чукча читатель"

UseCase 0: надоело переподключать плату с RP2040 и захотелось загружать прошивку из IDE по кнопке "Run"
UseCase 1: хочется пошаговой отладки, а не принтами.

Установил на одну из плат DebugProbe и попробовал подключиться.

Оказалось не все так просто - OpenOCD плевался на неизвестное устройство:

Привет, Хабр! Меня зовут Владимир Захаров (@‌vzkhrv), я расскажу про SSR. На самом деле, утечки памяти работают в JavaScript везде – и на сервер-сайте, и на клиенте, поэтому информация будет полезна даже тем, у кого пока нет SSR. Давайте чуть подробнее познакомимся. Я ведущий фронтэнд-разработчик, около 8 лет в отрасли. В Зарплате.ру больше не работаю, но основной опыт, о котором хочу рассказать, получен именно там. Я люблю плавающие баги, разговоры о техдолге и шутки про ненастоящих программистов. Поговорим про утечки в памяти в SSR, про работу с памятью и про то, как всё это выглядит в браузере и в nodejs. Ну, и естественно, как со всем этим жить.

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

Всем привет! Меня зовут Александр, я занимаюсь backend-разработкой в KTS. 

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

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

Переходы между тайлами… снова

С чего начать

1. ptrace(PTRACE_TRACEME, 0, NULL, NULL) сделает родителя текущего процесса отладчиком для него. Никакого содействия от родителя при этом не требуется; man ненавязчиво советует: «A process probably shouldn't make this request if its parent isn't expecting to trace it.» (Где-нибудь ещё в манах вы видели фразу «probably shouldn't»?) Если у текущего процесса уже был отладчик, то вызов не удастся.
2. ptrace(PTRACE_ATTACH, pid, NULL, NULL) сделает текущий процесс отладчиком для pid. Если у pid уже был отладчик, то вызов не удастся. Отлаживаемому процессу шлётся SIGSTOP, и он не продолжит работу, пока отладчик его не «разморозит».

Я наткнулся на статью Нареша Джоши о копировании и клонировании и был удивлён ситуацией с производительностью. У клонирования есть проблемы с финальными полями. А учитывая тот факт, что интерфейс Cloneable не предоставляет метод clone, то для вызова clone вам необходимо будет знать конкретный тип класса.