Отладка *

Как всем нам известно, процесс отладки это такая вещь, важность которой трудно переоценить. Причем, понимая важность таких методов как дебажное моргание светодиодами и вывод дебажных сообщений в порт, я остаюсь при мнении, что эффективнее пошаговой отладки пока ничего не придумано. Однако, задача пошаговой отладки становится не такой тривиальной в случае программирования под Linux на встраиваемых системах (таких как rasbery pi, virt2real или промышленные процессорные модули).

Данную задачу в Linux призвана решать стандартная связка программ GDB и gdbserver. Идея в том, что пишешь на компе программу (host в терминологии GDB), компилируешь её и заливаешь на целевое устройство (target). Далее запускаешь на целевом устройстве (target) отлаживаемый файл и gdbserver, а на хосте GDB и вперед.

Данная заметка может оказаться полезной для людей, который пишут bare-metal код и используют ThreadX в своих задачах (по собственному выбору или по навязыванию SDK). Проблема в том, что что бы эффективно отлаживать код под ThreadX или другую многопоточную операционную систему нужно иметь возможность видеть эти самые потоки, иметь возможность посмотреть стек-трейс, состояние регистров для каждого потока.

OpenOCD (Open On Chip Debugger) заявляет поддержку ThreadX, но не сильно явно оговаривает её широту. А штатно, на момент написания статьи, в версии 0.8.0, это всего два ядра: Cortex M3 и Cortex R4. Мне же, волею судеб, пришлось работать с чипом Cypress FX3 который построен на базе ядра ARM926E-JS.

Под катом рассмотрим что нужно сделать, что бы добавить поддержку вашей версии ThreadX для вашего CPU. Акцент делается на ARM, но, чисто теоретически, вполне может подойти и для других процессоров. Кроме того, рассматривается случай, когда доступа к исходникам ThreadX нет и не предвидится.

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

• когда запись в файл — консоль драматически сказывалось на воспроизодимости бага;
• когда мульти(процессорное/поточное) приложение часто обращается к драйверу и ты не можешь сопоставить временные метки и потоки;
• когда баг воспроизводится на стороне кастомера, сеанс teamviewer бесполезен, да к тому же версия с отладочными символами private;
• когда системное приложение падает до того, как система успеет скинуть логирование на диск;
• или когда макрос для логирования выглядит в лучшем случае как

  #define TraceDbg(format, ...) \
      printf( "(p %d, t %d) - (%s,%d) %s(): " format, GetCurrentProcessId(), GetCurrentThreadId(), __FILE__, __LINE__,__FUNCTION__, __VA_ARGS__ );
  

• когда придумываешь очередной способ вывести на экран ipaddr или UUID

В статье я представлю быстрый, надежный и универсальный для отладки с минимальным оверхедом инструмент диагностики, предлагаемой MS для системных приложений — WPP, рассмотренный частично в публикации «EventTrace for Windows. Высокоскоростная передача отладочных сообщений драйвера по сети».

Не все знают, что в InterSystems Caché есть встроенный инструмент для профилирования кода, который называется Caché Monitor.

Основное его назначение (очевидно) – сбор статистики по исполняющимся в Caché программам. Он может предоставлять как общую статистику по всем программам, так и детализированную Line-by-Line статистику по каждой отдельной программе.

Доброго времени суток,

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

Предыстория

В своем проекте мы активно используем отечественное геометрическое ядро C3D Kernel. Эта библиотека предоставляет большое количество классов для работы с кривыми, телами, поверхностями и т.п. Эти классы имеют сложную структуру и в процессе отладки приложения, используя стандартные средства визуализации Visual Studio, трудно понять, какая, например, поверхность хранится в конкретной переменной. А при отладке сложных алгоритмов очень важно понимать, что происходит с объектом на каждом шаге алгоритма.

Вчера мне пришло уведомление о том, что открыто beta-тестирование профайлера от SensioLabs - blackfire.io

Здравствуйте, уважаемые читатели Хабра.
После небольшого перерыва я продолжаю публикацию моих заметок (первая, вторая) о разработке и отладке компонентов UEFI на открытой аппаратной платформе Intel Galileo. В третьей части речь пойдет от подключении JTAG-отладчика на базе FT2232H к Galileo и о настройке отладочного окружения для нее.

Каждый программист в своей жизни должен хотя бы раз написать свой собственный логгер.
Народное изречение

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

Итак, Application Log, также известный как SLG0 и SLG1…

Техники перехвата функций в Linux хорошо известны и описаны в интернете. Наиболее простой метод заключается в написании динамической библиотеки с «функциями-клонами» и использовании механизма LD_PRELOAD для переопределения таблицы импорта на этапе загрузки процесса.

Недостаток LD_PRELOAD в том что необходимо контролировать запуск процесса. Для перехвата функций в уже работающем процессе или функций отсутствующих в таблице импорта можно использовать «сплайсинг» — запись команды перехода на перехватчик в начало перехватываемой функции.

Также известно, что в Python имеется модуль ctypes позволяющий взаимодействовать с данными и функциями языка Си (т.е. большим числом динамических библиотек имеющих Си интерфейс). Таким образом ничто не мешает перехватить функцию процесса и направить её в Python метод обёрнутый в С-callback с помощью ctypes.

Это перевод второй части публикации «Меня попросили взломать программу на собеседовании». Оригинальный текст можно найти здесь.

Предисловие

Привет, ребята. Если вы не знаете, что означает «Часть 2», пожалуйста прочитайте Часть 1.
Для начала я хотел бы поблагодарить всех прочитавших первую часть, поскольку в итоге я получил массу отличных отзыв.

Так же я бы хотел устранить некоторые недопонимания:

1. Я более не работаю на данную компанию, я переехал в Барселону;
2. Я проходил данное интервью почти год назад;
3. Программы я взламывал в облаке ($5 тариф, да, вы угадали компанию), поэтому я не считаю, что использование root@'a является проблемой — я могу пересоздать новую среду за пару секунд. В итоге я все же переключился на пользователя eren@, так как gdb не принимал рутовые инит файлы.
4. Не забудьте прочитать окончание статьи — вам обязательно понравится!

Поехали

На этот раз мы будем работать не с дверью, а с ядерной ракетой.

2-wire JTAG (он же двухпроводной JTAG, он же CompactJTAG, он же cJTAG) – это новомодный интерфейс, являющийся частью стандарта IEEE 1149.7-2009. Он обеспечивает ту же и даже большую функциональность, что и обычный JTAG (IEEE 1149.1), но использует всего два сигнала вместо четырех.

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

TL;DR Меня попросили взломать программу на собеседовании. И я получил работу.

Всем привет,

Я собеседовался на позицию инженера программной безопасности, они спрашивали в основном разные низкоуровневые вещи. Некоторые ответы я знал, некоторые нет.
Потом они прислали email с защищённым и зашифрованным бинарником, который нужно было взломать.
Когда я добрался до дома, я скачал его и увидел, что он спрашивает пароль. Они хотели, чтобы я нашёл этот пароль.
Вот что я увидел при первом запуске:

Здравствуйте, уважаемые хабрачитатели.

Многим из вас может быть интересна тема разработки и отладки кода UEFI-драйверов и приложений, которая пока еще недостаточно широко освещена в сети, но к которой мне посчастливилось иметь непосредственное отношение.

В связи с этим я планирую написать цикл статей о разработке и отладке UEFI-драйверов на аппаратной платформе Intel Galileo Gen 1, т.к. эта платформа обладает, на мой взгляд, наилучшим соотношением цена/качество для вышеуказанной задачи.

Первая часть статьи является вводной, в ней я расскажу о стандарте UEFI, проекте TianoCore и его недостатках, o внезапном решении Intel и их плате Galileo, о причинах выбора именно этой аппаратной платформы в качестве базовой и о планах на следующие части.

Браузер Google Chrome поставляется с превосходными инструментами для разработчика, они же есть в Яндекс.Браузере, новой Опере, и в других браузерах, основанных на базе Chromium.

Среди них есть потрясающие инструменты для работы с памятью, ознакомиться с которыми можно в статье пользователя Panya — «Как находить и устранять утечки памяти на примере Яндекс.Почты».

Javascript хранит объект в памяти до тех пор, пока на него есть хоть одна ссылка. Как только вы удаляете все ссылки на объект, он уничтожается сборщиком мусора.

Таким образом, чтобы удалить объект, нужно удалить все ссылки на него.

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

В начале марта я имел удовольствие посетить команду разработки Direct3D в главном офисе Microsoft в Редмонде. По ходу одной из дискуссий об отладке 3D приложений они посоветовали мне использовать новую возможность DirectX10\11 для отладки шейдеров.

Я использовал эту технику для отладки кода тесселяции под DirectX 11 (этот код приведён ниже), но и DirectX 10 обладает теми же возможностями и портирование будет достаточно тривиальным.

Что мы вообще пытаемся сделать?

Нам интересно получить результаты работы выполняемых на GPU шейдеров (вершинных, геометрических, тесселяции) для последующей обработки этих данных с помощью CPU. При этом мы хотим и видеть результаты просчёта графики на экране, и иметь все координаты в виде буферов и структур в оперативной памяти, откуда мы их уже сможем прочитать, записать в лог, использовать для дальнейших расчётов.

В этой статье дается простая короткая инструкция как пропатчить third-party приложение под iOS что бы отключить ASLR при отладке. Предполагается что у читателя в наличии:

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 и понимать зачем его отключать

Что ж, приступим.

Так уж случилось, что по долгу работы очень много времени провожу с операционными системами семейства GNU/Linux. Основным видом моей деятельности является разработка программного обеспечения на С++.

Так вот, основной проблемой при использовании отладчика – это отображение сложных контейнеров, например, stl-контейнеров.

Решение, которое я предлагаю, актуально для gdb. Этот отладчик поддерживает скрипты, написанные на языке python, а механизмы отображения сложных объектов, называются pretty printers. Т.е. чтобы отладчик отображал нам все правильно, необходимо указать ему где находятся скрипты с этими самыми pretty printers. Для указания отладчику дополнительных команд необходим файл .gdbinit.

Итак, попробую оформить все, как инструкцию, так и читать удобней, и сам не забуду.

Трассировка используется во многих видах ПО: в эмуляторах, динамических распаковщиках, фаззерах. Традиционные трейсеры работают по одному из четырех принципов: эмуляция набора инструкций (Bochs), бинарная трансляция (QEMU), патчинг бинарных файлы для изменения потока управления (Pin), либо работа через отладчик (PaiMei, основанный на IDA). Но сейчас речь пойдет о более интересных подходах.

Зачем отслеживать?

Задачи, которые решают с помощью трассировки можно условно разделить на три группы в зависимости от того, что именно отслеживается: выполнение программы (поток управления), поток данных или взаимодействие с ОС. Давай поговорим о каждом подробнее...

Глупо спорить с тем, что аналоговое видеонаблюдение уходит в прошлое: дешевые IP камеры дают картинку сопоставимого качества с дорогими аналоговыми. Помимо этого, IP камеры не ограничены сверху ничем, кроме производительности регистратора, тогда как аналоговые камеры требуют жесткого соответствия приёмной карты, согласования уровней сигнала передатчиков/усилителей/приемников и прочего шаманства.
Конструируя систему на базе IP камер в любой момент можно снять камеру и заменить на более качественную — если при этом сохранить IP адрес и логин-пароль, то, скорее всего, даже не придётся менять настройки приемника — просто в архив пойдёт более качественная картинка.
С другой стороны, это накладывает ограничения на регистратор — он должен быть готов работать с любым разрешением, любым битрейтом, любым кодеком и любым протоколом… Ну или по крайней мере, корректно работать с заявленным.

В мире софта есть два пути — есть linux-way: это набор небольших программ, каждая из которых делает одну функцию, но очень хорошо; и есть windows-way: это огромные кухонные комбайны, которые умеют делать всё, и немного больше. Главная проблема linux-way — это отсутствие интерфейса. Чтобы получить всю пользу придётся скурить маны (или хотя бы прочитать --help), и поэкспериментировать. А так же сообразить, что и с чем можно скомбинировать и как. Главная проблема windows-way — это потеря основной функции. Очень быстро при обрастании доп.функционалом теряются тесты ключевого функционала, и со временем начинаются проблемы даже с ним. А еще при этом начинается инерция мышления: «это главная функция, она оттестирована сильнее всего, там бага быть не может, пользователь делает что-то не то».

В этой статье хочу рассказать, а также показать настройку полезного инструмента для удаленной разработки от компании JetBrains встроенное в IDE Pycharm. Такой инструмент есть уже давно, но многие разработчики относятся к этому не серьезно, и для внесения изменений в проект предпочитают разворачивать его локально. Когда намного легче на том-же сервере, сделать копию части проекта и изменять или тестировать на другом порту с помощью встроенных средств удаленного интерпретатора Pycharm. Конечно не во всех ситуациях это хороший вариант, но для правки, и доработки небольших проектов очень даже подходит. А если проект с нуля, то создавая его на удаленном сервере, исчезает потребность в переносе и адаптации его под сервер(хостинг), которые неизбежно ведут к появлению множества багов и несовместимостей.

К тому же такой подход нас избавляет от таких проблем:

• на разных серверах свой Unix и свои приколы, разворачивать локально и подгонять среду под особенности того или иного сервера может занять приличное количество времени;
• разные версии python;
• И если в файле req.txt для Django не указаны все зависимости;
и т.д.