Отладка *

Так уж случилось, что по долгу работы очень много времени провожу с операционными системами семейства 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 не указаны все зависимости;
и т.д.

Система логирования — незаменимый инструмент для протоколирования работы приложений. Для тех, кто не хочет реализовывать его самостоятельно, на C++ уже существует бессчётное количество готовых библиотек (Log4cplus, Apache log4cxx, Boost.Log и тд.), однако Easylogging++ отличается простотой использования и компактностью, не требует сторонних библиотек или инсталляции. Весь её код содержится в одном единственном заголовочном файле, который просто необходимо включить в код приложения.

Данная статья предлагает краткий обзор функционала Easylogging++ и примеры использования этой библиотеки.

Вы используете в своем приложении электронную почту, не так ли? Это, в общем-то, риторический вопрос, конечно используете. Ей уже больше 30 лет, а это по прежнему самое популярное средство коммуникации на планете. Вот некоторые статистические данные от Pingdom:

• 2,2 млрд. — Количество пользователей электронной почты по всему миру
• 144 млрд.- Объем отправляемых электронных писем ежедневно во всем мире
• 4,3 млрд.- Количество почтовых клиентов во всем мире

Потрясающе!

Зачем нужна эта статья?

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

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

Тесты проходят, вы хвалите себя и продолжаете работу. Но спустя некоторые время вы получаете звонок от своего заказчика. Он жалуется, что его клиенты получили странные. Он расстроен и хочет получит ответ.

Было такое? Не хочется, чтобы повторилось? Есть решение — MailCatcher. Если вы не слышали о нем то вкратце:

… Супер-простой SMTP-сервер, который перехватывает любое отправленное сообщение и выводит его в веб-интерфейсе. Запустите mailcatcher, в настройках вашего приложения укажите smtp://127.0.0.1:1025 вместо SMTP-сервера по умолчанию, и затем просматривайте почту, которая была отправлена по адресу 127.0.0.1:1080

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

Сейчас я хочу показать вам, как настроить, запустить и использовать MailCatcher.

В этой статье я расскажу о простом методе заработка в сети перехвата HTTP/HTTPS трафика iOS приложений, включая трафик приложений использующих certificate pinning (а это например Twitter, Facebook и куча других приложений). От прочих методов, где бедным людям рекомендуют в командной строке руками генерировать какие-то сертификаты и куда-то их запихивать, этот метод отличается (относительной) безгеморройностью, хотя кое-какие телодвижения сделать конечно прийдется.

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

DDMS (Dalvik Debug Monitor Server) — безумно полезный инструмент для отладки приложений, который идет в комплекте с Android SDK, о котором почему-то особо и не сказано на хабре, впрочем как и в примерах google он представлен в очень скромном виде. Я бы хотел раскрыть его возможности и показать на что он способен. Вкратце:

• изучать информацию о работающих потоках;
• анализировать heap на количество свободной и занятой памяти;
• анализировать какие объекты чаще создаются, их размер и другое (Allocation tracker);
• находить проблемные участки кода, которые долго работают и требуют оптимизации (Method profiling). Это я советую знать всем.

Об этих вещах будет рассказано в рамках данной статьи. И для справки, менее интересное, что довольно тривиально и о чем НЕ будет рассказано в рамках данной статьи:

• работать с файловой системой эмулятора или устройства;
• находить информацию об ошибках (привет LogCat);
• эмулировать звонки/смс/местоположение;
• использовать инструмент Network Statistics.

Все идет от лени. Вы получили чужой очень большой проект в котором нужно сделать небольшие правки, или же написали скрипт и сразу не очевидно, что в нем еще требует оптимизации. Как быть? Читать и анализировать код, выводить каждый шаг на экран или в файл (var_dump() и т.д.) не всегда эффективно, ведь можно воспользоваться средствами отладки, которых на сегодняшний день очень много. Кратко перечислю часто встречающиеся…

Эта простая статья скорее для начинающих разработчиков Java, хотя я нередко вижу и опытных коллег, которые беспомощно глядят на stack trace, сообщающий о NullPointerException (сокращённо NPE), и не могут сделать никаких выводов без отладчика. Разумеется, до NPE своё приложение лучше не доводить: вам помогут null-аннотации, валидация входных параметров и другие способы. Но когда пациент уже болен, надо его лечить, а не капать на мозги, что он ходил зимой без шапки.

Итак, вы узнали, что ваше приложение упало с NPE, и у вас есть только stack trace. Возможно, вам прислал его клиент, или вы сами увидели его в логах. Давайте посмотрим, какие выводы из него можно сделать.

Приветствую тебя, уважаемый читатель!

Offtop

В этом топике я хотел бы рассказать о том, как можно получать доступ к тому, что принадлежит нам, но косвенно.
Любой софт — это чья-то собственность: кто-то сидел и шевелил своими мозгами, чтобы произвести на свет очередное «чудо».
Но вне наших девайсов речи о софте не может и быть. Понятие «софт», в таком случае, будет означать не более чем «мягкость».
Это очевидно.
Именно поэтому мы имеем право вытворять с любым программным кодом, выполняющимся на нашем устройстве, все, что пожелает душа…

Intro

Думаю, начать стоит с самого начала. Все началось с моего обнаружения пользовательской зависимости окружающих к небезызвестной игре 2048. Мне, конечно же, стало интересно, чем эта игра так захватывает людей, поэтому я решил сам ее попробовать. Через несколько минут я понял ее суть и мне эта игра тоже стала интересна.
Должен признаться, более 5000 очков мне набирать не удавалось никак, а до 2048 было еще слишком долго…
Тем временем окружающие «игроки» с легкостью набивали по 10-16тыс очков, а некоторым удавалось даже достигать 2048 в клетке.
Что ж, спустя некоторое время у меня возникла идея тупо взломать эту игру, чтобы не «убивать» время на ее прохождение( она слишком долгая в прохождении, но от этого не менее затягивающая ). А еще спустя пару дней, об этом же меня попросили и мои знакомые.
Это означало одно: пора браться за дело…

Итак, у нас есть задача: пофиксить баг, производитель от которого открещивается, клиенты не замечают, а жить хочется. Есть камера, поток от неё на UDP просто адово ломается, поток на TCP работает, но постоянно рвутся коннекты (и при каждом обрыве пропадает 3-5 сек видео). Виновны в проблеме все (и камера и софт), но обе стороны утверждают что у них всё зашибись, то есть ситуация обычная: ты баг видишь? нет. А он есть.

Недавно я уже поднимал волну о баге TCP стриминга камер, но тогда я её катил исключительно на китай. А проблема куда как шире. Для себя я проблему решил, страждущим выкладываю прошивки с фиксом.

А теперь садитесь поудобнее, я поведаю вам об этом баге подробно.

Введение в «Checkpoint Group»

Понятие и реализация «Сheckpoint Group» изначально появились в SAP Web Application Server (SAP WebAS) 6.20 и целиком относятся к области контроля правильности и возможности отслеживания переменных. При грамотном применении, технология облегчает работу по отладке и повышает качество ABAP кода.

Mozilla выпустила инструмент, который наверняка многим облегчит жизнь: это фреймворк RR под Linux для записи и последующего воспроизведения хода выполнения программы. Воспроизведение происходит абсолютно детерминированно, то есть с теми же регистрами и адресами памяти — и неизменно с тем же сбоем (если он был). Другими словами, можно бесконечно гонять тесты, а как только появится баг — не спеша его изучить в офлайне, прокрутив запись сколько угодно раз. Записываются все деревья процессов и потоков.

RR создан для точного воспроизведения багов, которые проявляют себя непредсказуемо. В таких случаях при отладке стандартными средствами нет смысла запускать программу снова: не факт, что баг опять проявится. Эта проблема постоянно портит жизнь разработчикам. Вот почему в Mozilla решили создать такой фреймворк.

Многие интернет-магазины попадают в Яндекс.Маркет, не все там остаются надолго. Одно из условий присутствия в ЯМ-е – наличие корректного прайса в специальном формате YML.

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

Данная статья – попытка обобщить те ошибки, с которыми сталкиваются программисты, впервые создающие инструменты (будь то автономный скрипт или плагин для CMS) для генерации YML-файла. Тем, кто с этим чудным форматом имел дело раньше, статья уже будет не столь интересна, ибо всё шишки набиты. Впрочем, вдруг и ветераны борьбы за своё место под солнцем Яндекса узнают что-то новое для себя. А то и поделятся собственным фронтовым опытом.

В этой статье мы ищем (и, что характерно, находим!) критический баг в CoreGraphics в iOS. Сразу скажу, что на полноценную уязвимость этот баг конечно не тянет — его эксплуатация не приводит, например, к arbitrary code execution. Однако этот баг позволяет аварийно завершать приложения которые используют WebKit: Mobile Safari, Google Chrome для iOS, всяческие почтовые клиенты и т.п., что тоже может быть полезно для хакера в некоторых ситуациях. Итак, приступим к поискам.

Всем привет! Меня зовут Дмитрий Чепель, я — эксперт в компании Acronis. Так уж получилось, что ко мне обращаются с проблемами, которые не удалось решить моим коллегам. Кто-то думает, что у меня есть некое «разработческое чутьё», интуиция. Не знаю, как вы, а я считаю, что интуиция — это такой же инструмент разработки, как и остальные, и её можно и нужно улучшать и тренировать.

В связи с узурпацией должности управдома нашего МКД, и необходимости «причесать» общественный беспорядок, потихоньку конструирую систему видеонаблюдения.
Разумеется, финансирование минимальное, планы — грандиозные, поэтому собирается всё из подножного корма.
Подробности чуть позже, а вот один из интересных багов, который заставил перебрать много чего.

Итак, началось всё с малого — простенькая купольная камера, бралась самая паршивая по принципу "только б IP и купол". После пошел процесс перебора софта (тема отдельного поста, будет, опять же, позже)… В конце зафиксировался на Macroscop в один канал. Стояла пару месяцев, есть-пить не просила, наркоманов гонять помогала.

И вот работает вроде всё, но как-то подлагивает периодически. Грешил на всё: на проц, на сеть, на софт, на погоду на марсе… Саппорт по логам говорит, что-де камера периодически отваливается.

Upd