Отладка *

ПЭВМ Дуэт — это российский клон ZX Spectrum 48k, производился Лианозовским электромеханическим заводом (ЛЭМЗ). Это мой самый первый компьютер и он со мной до сих пор. С юного возраста я начал постигать на нем азы программирования, микропроцессорных архитектур и проектирования цифровых схем. Но с тех пор мне не давал покоя вопрос: где системный монитор? Ведь он упоминается в документации. В стандартном ZX Spectrum я не припомню наличия какого-либо системного монитора. И в документации про системный монитор больше ни слова. Существует Монитор для 48к в ПЗУ версии от 1990г. Однако, после включения, ПЭВМ Дуэт выводит на экран вместо стандартного приветствия — "(с) 1982 sinclair research ltd" другое приветствие: "(с) DUET". А это значит, что ПЗУ там всё же изменено. А может быть есть аппаратные возможности мониторинга? К примеру, клон Орель БК-08 имеет целый ряд доработок: теневое ОЗУ, кнопка NMI и монитор MZ80. Было бы очень интересно, спустя столько лет, найти какие-то скрытые возможности своей железки.

Наконец-то я нашел ответ на вопрос, который меня периодически волновал все эти годы.

Большинство потребителей имеют уже сложившееся мнение о том, что касается услуг web-хостинга. Если вы будете искать отзывы о любом хостинг-провайдере, вы обнаружите десятки результатов. И обычно, негативных отзывов там намного больше, чем положительных. Я думаю, я смогу это исправить, поэтому делюсь с вами задачами, с которыми мне приходится сталкиваться как оператору поддержки хостинга для WordPress, а также их решениями.

Я собрал список плохих web-решений, а также рекомендаций о том, чего делать на вашем сайте не стоит. Список основывается на тысячах часов общения с клиентами, а также поддержки и устранения неполадок, с которыми я сталкиваюсь ежедневно. Что-то из предложенного будет достаточно примитивным, а какие-то вопросы будут более продвинутого уровня. Многое из описанного может отделять успешный сайт на WordPress от провального. Ведь, несмотря на то, что выбор правильного web-хостинга очень важен, вы должны уделять достаточно времени оптимизации сайта на WordPress, чтобы он был успешным.

Code review может быть большой болью для команды, которая только начинает его внедрять. Вы в любом случае наступите на много граблей: будете проводить ревью дольше, чем пишете код, устраивать смертельные споры про расположение скобочек и разбираться, можно ли сливать ветку в master до аппрува команды или нет. Я собрал ряд практик, которые помогут вам сделать процесс адаптации чуть менее болезненным — по крайней мере, мне они точно помогли.
 
Этот материал — краткая выжимка моего опыта, накопленного за несколько лет работы в крупных командах мобильной разработки. Опыт по большей части в мобильной разработке, что оказало влияние на используемые примеры и ссылки. Для тех, кто предпочитает не читать, а смотреть, в течение пары месяцев должно появиться видео с конференции Mobius, где я рассказываю доклад на эту же тему, но с кучей подробных практических примеров.
 

Первый раз я увидел команду duel в gdb на каком-то древнем IRIX-е, лет пятнадцать назад. Это была невероятно крутая штука для просмотра разных связанных списков, массивов структур, и прочих подобных конструкций. Помечтал, мол, если б в Линуксе такая была, и забыл. Лет десять назад вспомнил, погуглил — оказалось, что DUEL, это вообще-то патч 93-го года для gdb 4.6, а вовсе не что-то уникальное в IRIX. Только автор по идейным соображениям выпустил его как public domain, а gdb-шники были тоже идейные и хотели GPL, так что попасть в upstream этому патчу не грозило. Я портировал его на тогдашний gdb 6.6.2, отдал в gentoo и до выхода 7-го gdb наслаждался жизнью. Потом duel из gentoo выкинули, портировать на новый gdb было сложно, никто не взялся. А недавно я его попробовал оживить. Только вместо патча (надо собирать вместе с gdb из исходников, использует всякие внутренние gdb-шные функции) я его написал с нуля на питоне. Теперь Duel.py (так называется новая реализация Duel-а) грузится в gdb на лету, и, надеюсь, Python API не будет меняться от версии к версии так, как недокументированные gdb-шные потроха. Итак, встречайте: DUEL — высокоуровневый язык анализа данных для gdb.

В этом году в рамках PG Day'17 Russia пройдет двухдневный поток докладов по Oraclе DB: Ярослав Киселев расскажет о мониторинге и диагностике производительности приложения с точки зрения Oracle DB, Николай Кудинов сделает технический ликбез о минимизации ожиданий log file sync и log file parallel write, Александр Халухин из Deutsche Bank готовит интенсивный мастер-класс о диагностике производительности Oracle Database. Полный список выступлений смотрите у нас на сайте!

Для специалистов, интересующихся коммерческими базами данных мы подготовили перевод публикаций от специалистов по базам данных из CERN. Сегодняшний материал открывает цикл из нескольких статей, посвященных трассировке и отладке производительности Oracle DB с помощью SystemTap.



Эта статья посвящена использованию SystemTap для поиска и устранения неполадок в СУБД Oracle. В частности, вы узнаете, как исследовать процессы Oracle и их функции userspace. Эти методы будут полезны и увлекательны для всех, кто заинтересован в том, чтобы заглядывать под капот технологий и повышать свою эффективность в поиске и устранении неисправностей, а также в исследованиях производительности.

Вчера потратил полдня в попытках разобраться с причиной появления исключения в PHP-коде, а с утра в голову пришла мысль, что причиной был я сам. Вернее, использование мной отладчика в IDE PhpStorm для трассировки хода выполнения кода.

Условия возникновения ситуации — под катом.

В действительности все совершенно иначе, чем на самом деле.
Антуан де Сент-Экзюпери

Многое в разработке руководства пользователя регламентировано и описано ГОСТами. Но при создании больших гетерогенных систем могут возникать вопросы, не до конца освещенные этими документами.

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

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

В недавнем интервью с Джоном Скитом мы пришли к выводу, что профессиональная работа с любой технологией подразумевает умение диагностировать проблемы и понимать, как ваши приложения работают под капотом. Вдогонку к тому разговору, я узнал у Саши goldshtn Гольдштейна, одного из лучших в мире экспертов по производительности .NET, автора книги «Pro .NET Performance», на какие инструменты следует обратить внимание .NET-разработчикам.

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

Вот уже 15 лет прошло со времен первого релиза Xdebug. Прекрасный повод вновь представить эту систему миру и объяснить как и почему она делает то что делает.

Xdebug — это расширение для PHP (должно быть скомпилировано и установлено в процессе установки PHP) которое представляет разработчику следующий функционал для отладки:

Иногда при анализе какой-нибудь платной программы малвари случается так, что она не хочет нормально работать, если в памяти есть отладчик или включён отладочный режим Windows.
В таких ситуациях помогает использование виртуальной машины с подключённым к ней отладчиком (например, GDB или IDA). Это если программа не пытается «сломаться» и в виртуальной машине тоже.

Изображение: Julien Dumont, Flickr

К сожалению, иногда случаются ситуации, когда система перестает работать или начинает безудержно потреблять ресурсы, а логи и системные метрики не могут помочь. Ситуация еще усугубляется тем, что на системе в продакшене нет Visual Studio или какого-либо отладчика, невозможно поотлаживаться удаленно. Чаще всего даже нет возможности получить доступ этой машине. В данном случае единственным решением является анализ дампа памяти процесса. Я хочу описать несколько общих сценариев поиска проблем на таких дампах. Это поиск взаимоблокировок, утечек памяти и высокого потребления процессорных ресурсов.

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

less установлен у всех, все привыкли с ним работать, знают о базовых вещах, как поиск вперед-назад, фильтрация по &, переход в конец(G) файла, переход в начало(g) и так далее.

А так же, все уже смирились с тем, что в любой момент, при добавлении фильтра less может подвиснуть на неопределенный срок, выводить по строчке в 5 секунд и так далее. В конечном счете, особенно при считывании логов с stdin — приходится быть аккуратным. Фильтр может сработать, а может и не сработать.

Собственно, в тот момент, что и мне выпала участь в течении нескольких дней пройтись через этак пару сотен лог-файлов — стало очевидно — мир нужно менять к лучшему…

Под катом демо (gif 2.2mb) и немного истории.

Сегодня просматривая публикацию Егора Бугаенко When Do You Stop Testing!, с удивлением обнаружил, что немногие понимают и задумываются о том, что проблема тестирования и утверждения того, что система не имеет недостатков принципиально не решаема. Это кстати еще актуально и в связи с внедрением электронных выборов, и требованиями со стороны официальных лиц и журналистов доказательств отсутствия дыр в системе безопасности. Например у нас (Эстония) эта дискуссия идет полным ходом, и политики хотят получить стопроцентные доказательства надежности системы электронных выборов. Публичные политики, как правило незнакомы с логикой в её формальном виде. А Юм и Поппер, в лучшем случае, напоминают о каких то скучных философских семинарах, о которых лучше забыть. Но когда я слышу о том, что тестер или сеньор начинает вполне серьезно доказывать, что код протестирован и ошибок нет совсем, мое лицо приобретает это выражение:

Продолжая серию публикаций по докладам на конференциях, мы остановились на лучшем докладе DotNext 2016 Moscow, в которой Саша goldshtn Гольдштейн рассказывает о возможностях WinDbg для отладки .NET приложений. Этот действительно мощный инструмент позволяет решать задачи, с которыми не справляется встроенный отладчик Visual Studio.

Особенно этот материал будет полезен тем, кому сложно смотреть доклады на английском языке, так как расшифровка переведена на великий и могучий!

Хабра, привет!

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

Разговор о программировании под Linux медленно перешел к тому, что этот человек стал утверждать, что сложность системного программирования на самом деле сильно преувеличена. Что язык Си прост как спичка, собственно как и ядро Linux (с его слов).

У меня был с собой ноутбук с Linux, на котором присутствовал джентльменский набор утилит для разработки на языке Си (gcc, vim, make, valgrind, gdb). Я уже не помню, какую цель мы тогда перед собой поставили, но через пару минут мой оппонент оказался за этим ноутбуком, полностью готовый решать задачу.

И буквально на первых же строках он допустил серьезную ошибку при аллоцировании памяти под… строку.

char *str = (char *)malloc(sizeof(char) * strlen(buffer));

buffer — стековая переменная, в которую заносились данные с клавиатуры.

Я думаю, определенно найдутся люди, которые спросят: «Разве что-то тут может быть не так?».
Поверьте, может.

А что именно — читайте по катом.

Что gdb можно как-то улучшать на питоне, знает каждый, кто хоть раз заглядывал в документацию. А кто хоть раз просматривал ее по диагонали, знает про такую штуку, как «Pretty Printers» — которые вроде позволяют gdb красиво печатать разные сложные структуры. Я документацию по диагонали просматривал, хотя особо и не вникал. Но однажды, набирая в очередной раз что-то вроде (все примеры из исходников MariaDB, которые я дебажу по много раз каждый божий день, иногда исключая выходные):

(gdb) p/t table->read_set->bitmap[0] @ (table->read_set->n_bits+7)/8

Я подумал «а фигли?». И все заверте…

Я люблю графические отладчики. Обычные я тоже люблю, но графические — больше. Они дают ощущение сродни заглядыванию за кулисы театра во время выступления: «ага, вот эта декорация крепится так, а этот луч света падает отсюда, а у этого шкафа нет задней стенки...». Графический отладчик пробрасывает мостик понимания между текстовым кодом приложения и полученной красивой картинкой.

Но индустрия не балует нас обилием подобного инструментария. Есть графические отладчики от Intel, NVidia и AMD, но они не работают на чипах конкурентов и предназначены не столько для разработки\отладки, сколько для бенчмарков и хвастовства своими видеокартами. Они неплохо рассказывают ЧТО и КОГДА произошло, но плохо объясняют ПОЧЕМУ и КАК ИСПРАВИТЬ.

В другом лагере находится мой любимый RenderDoc, о котором я уже писал. Прекрасная утилита, написанная ребятами из Crytek для себя и людей. Открытый код, поддержка всех вендоров, DirectX11 (с планами на Вулкан и DirectX12), куча мелких полезных мелочей.

Вторым представителем когда-то был PIX — утилита для анализа производительности DirectX9. Задумывалась она как инструмент для разработки под XBox (само название это аббревиатура от Performance Investigation for XBox), но хорошо работала и для десктопных приложений. До того момента, пока не умерла (с выходом DirectX 10/11 и новых версий Windows). Microsoft, у которого в очередной раз маркетологи победили инженеров, объявил единственным инструментом для графической отладки Visual Studio, в которой именно для этих целей было много лишнего, многого не хватало, а кое-что было и вовсе невозможно. Студия — прекрасный инструмент для программирования, но далеко не столь хорошая вещь для изучения, профилирования и отладки графического кода (тем более чужого).

Всё это уныние продолжалось несколько лет, пока инженеры Microsoft не одержали временную победу и в январе 2017 года Microsoft объявила о запуске беты полностью обновлённой версии PIX для DirectX 12!

Давайте же посмотрим, что мы получили.

После установки SSDkeeper заметил очень странную картину — через некоторое время работы компьютера количество доступной памяти заметно снижается. При стандартном наборе постоянно запущенных приложений (браузеры, торрент и DC++ клиент) из 16Гб остается примерно половина.

Диспетчер задач не давал ответа на вопрос об утечке памяти, поэтому следующей утилитой диагностики была RamMap:


На скриншоте приведено состояние системы уже после устранения проблемы, ранее Nonpaged Pool занимал порядка 4-6Гб.

В первой части был обзор возможностей. А в этой части рассмотрим, какие уже реализованы интерфейсы тестирования и как добавить свой…

Как естественное продолжение работы над libuniset2, возник проект uniset2-testsuite. Это свой небольшой велосипед для функционального тестирования. В итоге он развился до более-менее универсального решения с «плагинами». Написан на python. Если интересно почитать, то прошу… заходите.