Отладка *

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

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

Поэтому рано или поздно заказчик пришлёт письмо: «Почему, чёрт возьми, это занимает так много времени?» Не будем забывать, что у нас как инженеров-программистов есть окно в мир, которого они зачастую лишены. Они очень нам доверяют, но иногда кажущееся незначительным изменение отнимает действительно много времени. Из-за этого и возникают вопросы.

Что? Строки могут быть «грязными»?

Да, могут.

//.....Какой-то код
console.log(typeof str); // string
console.log(str.length); // 15
console.log(str); // "ччччччччччччччч"

Вы думаете, в этом примере строка занимает 30 байт?

А вот и нет! Она занимает 30 мегабайт!

В MSDN'овской статье Process Security and Access Rights есть интересная ремарка:

… if process A has a handle to process B with PROCESS_DUP_HANDLE access, it can duplicate the pseudo handle for process B. This creates a handle that has maximum access to process B.

Если вольно перевести это на русский, то тут говорится, что имея описатель на процесс с правом доступа PROCESS_DUP_HANDLE мы можем, используя функцию DuplicateHandle(...), получить описатель с максимально разрешенными масками доступа на этот процесс.

Код программных продуктов для машинного обучения часто бывает сложным и довольно запутанным. Обнаружение и ликвидация багов в нем — ресурсоемкая задача. Даже простейшие нейросети с прямой связью требуют серьезного подхода к сетевой архитектуре, инициализации весов, оптимизации сети. Небольшая ошибка может привести к появлению неприятных проблем.

Эта статья посвящена алгоритму отладки ваших нейронных сетей.

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

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

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

«В режиме трассировки программист видит последовательность выполнения команд и значения переменных на данном шаге выполнения программы, что позволяет легче обнаруживать ошибки» — сообщает нам Википедия. Сами будучи поклонниками Linux, мы регулярно сталкиваемся с вопросом, какими именно инструментами её лучше осуществлять. И хотим поделиться переводом статьи программиста Хонгли Лая, который рекомендует bpftrace. Забегая вперёд, скажу, что заканчивается статья лаконично: «bpftrace — это будущее». Так чем же он так впечатлил коллегу Лая? Развёрнутый ответ под катом.

На Хабре уже писали про перехват системных вызовов с помощью ptrace; Алекса написал про это намного более развёрнутый пост, который я решил перевести.

---

С чего начать

Общение между отлаживаемой программой и отладчиком происходит при помощи сигналов. Это существенно усложняет и без того непростые вещи; ради развлечения можете прочесть раздел BUGS в man ptrace.

Есть как минимум два разных способа начать отладку:

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, и он не продолжит работу, пока отладчик его не «разморозит».

Эти два метода полностью независимы; можно пользоваться либо одним, либо другим, но нет никакого смысла их сочетать.

Несколько дней назад команда инженеров Facebook отличилась — ее удостоили награды Most Influential POPL Paper Award. В среде специалистов по машинному обучению это весьма почетно. Награду вручили за работу Compositional Shape Analysis by Means of Bi-abduction, которая раскрывает нюансы Project Infer. Сам проект предназначен для обнаружения и ликвидации багов в коде мобильного приложения перед его деплоем.

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

Перевели статью Амита Соланки по отладке JavaScript-кода при помощи консольных команд. По словам автора, эти команды помогут значительно повысить производительность труда программиста при поиске багов и сэкономят кучу времени.

Давайте рассмотрим команды, которые действительно способны упростить жизнь любому программисту.

После многолетнего опыта работы с php и js, я привык иметь в ошибках стектрейс и смотреть на место, где произошла ошибка прямо из эррор-репорта. Пересев на Go пару лет назад, я был несколько удивлен, что в Go другие правила и нужно угадывать стектрейс по какой-нибудь строке типа `invalid character`. А если она произошла на проде и не известно, как ее воспроизвести, то это превращалось в целый аттракцион.

Поскольку я уверен, что не один от этого страдал, то сделал пакет, который умеет так:



→ GitHub

В этой публикации речь пойдет о синтетических модулях и символах отладочного движка Windows (debugger engine). То есть о сущностях, которые можно искусственно добавить в отладчик для раскраски адресов памяти.

Всем доброго времени суток!

Предлагаем вашему вниманию подробное описание открытого урока, посвящённого попарному тестированию. Мероприятие прошло всего пару дней назад и было приурочено к запуску курса «QA-специалист».

Преподаватель — Нина Деваева — Senior Tester, Team Leader и ISTQB-сертифицированный тестировщик, эксперт по направлению Quality Assurance.

На открытом уроке поговорили о необходимости такого вида техники тест-дизайна, как попарное тестирование (pairwise testing). Изучили кейсы применения на практике и подробно рассмотрели инструментарий, доступный для работы.

Всем привет!

Сегодня рассмотрим настройку удобной и красивой среды разработки для программиста микроконтроллеров с помощью набора полностью бесплатных инструментов разработки.

Все шаги проверены на виртуальной машине со свежеустановленной Ubuntu 16.04 xenial desktop x64.

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

Все настройки, касающиеся конкретного железа (в моём случае это контроллер STM32F429 и девборда STM32F429DISCO), нужно подменить на свои. То же самое касается и путей.

Если готовы, то

Всем привет!

В преддверии запуска курса «QA-специалист», который стартует уже через 10 дней, хотим поделиться материалом, который расскажет о новых подходах в тестировании и будет полезен всем, кто следит за новыми тенденциями и остается в тонусе.

С появлением технологий Agile и DevOps индустрия разработки программного обеспечения претерпевает серьезные перебои в работе. Это привело к развитию новых подходов к тестированию. Специалисты по обеспечению качества должны быстро адаптироваться к изменениям в отрасли тестирования ПО, чтобы оставаться актуальными. Вот список 10 тенденций тестирования программного обеспечения, на которые следует обратить внимание в 2019 году:

Читая Technology Radar от ThoughtWorks, я наткнулся на технику "Отдельный уровень логирования на каждый запрос (Log level per request)". Мы в Confirmit широко используем логирование, и мне стало интересно, как можно реализовать эту функциональность.

В конце прошлого года на Reddit представили плагин к kubectl, помогающий производить отладку в pod'ах кластера Kubernetes — kubectl-debug. Эта идея сразу же показалась интересной и полезной нашим инженерам, так что мы решили посмотреть на её воплощение и рады поделиться своими результатами с читателями хабры.

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

tl;dr: Диспетчер задач скрывает информацию о подкачке (paged memory) и виртуальном пространстве процесса. Лучше используйте Process Explorer из комплекта Sysinternals.

Привет всем,

В предыдущей статье мы успешно модифицировали ядро эмулятора игр на Sega Mega Drive / Genesis, добавив в него возможность отладки. Теперь пришёл черёд написания собственно плагина-отладчика для IDA Pro, версия 7.0. Приступим.

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

Товарищи реверсеры, ромхакеры: в основном эта статья будет посвящена вам. В ней я расскажу вам, как написать свой плагин-отладчик для IDA Pro. Да, уже была первая попытка начать рассказ, но, с тех пор много воды утекло, многие принципы пересмотрены. В общем, погнали!

Автор статьи — Крис Зибенманн, системный администратор Unix в университете Торонто

Время от времени в моей работе происходит нечто странное, что заставляет задуматься. Даже если сразу непонятно, какие следуют выводы. Недавно я упомянул, что мы нашли ошибку в GNU Tar, и история о том, как это произошло, — один из таких случаев.

Для бэкапа файл-серверов мы используем Amanda и GNU Tar. В течение долгого времени у нас периодически возникала довольно редкая проблема, когда tar сходил с ума при резервном копировании файловой системы с каталогом /var/mail, производя огромное количество выходных данных. Обычно этот процесс уходил в бесконечность и приходилось убивать дамп; в других случаях он всё-таки завершался, выдав терабайт(ы) данных, которые вроде бы отлично сжимались. Когда мне в очередной раз попался такой гигантский файл tar, я подверг его проверке — и выяснил, что он частично состоит из нулевых байтов, которые очень не нравятся команде тестирования tar -t, после чего всё возвращается в норму.

(Из-за этого мне стало интересно, появляются ли нулевые байты естественным образом у людей в почтовых ящиках. Оказалось, что поиск нулевых байтов в текстовых файлах не такой простой и да, они там есть).