Некоторое время назад мы с вами научились пользоваться DTrace. SystemTap представляет собой нечто похожее, но сильно заточенное под Linux и с рядом важных отличий. Во-первых, SystemTap не требует ручного добавления пробов в код ядра или приложений. Он работает и так, правда, требуя взамен знания исходников. Во-вторых, скрипты SystemTap транслируются в язык C и загружаются в ядро в виде модулей. За это приходится платить временем компиляции скриптов. Зато скриптовый язык SystemTap намного мощнее, чем у DTrace.
DTrace — это такая штука, присутствующая во FreeBSD, NetBSD, MacOS, Solaris и Linux. DTrace предназначен для динамической трассировки ядра системы и приложений в реальном времени, главным образом с целью их профайлинга и отладки. Сегодня мы попробуем поработать с DTrace во FreeBSD. Кроме того, мы установим DTrace и в Ubuntu, хотя по поводу стабильности такой конфигурации и остаются вопросы.
Типичный отладчик, такой как WinDbg или LLDB, позволяет выполнять программу шаг за шагом, просматривая значения переменных, создавая брейкпоинты, и так далее. Reverse debugging — это когда вы можете делать все то же самое, но не в прямом порядке, а в обратном, как бы «назад во времени». Сегодня мы познакомимся с двумя способами reverse debugging’а в Linux. Вероятно, эти способы работают и на других платформах, но я не проверял.
Бывает, что нужно отладить программу, а GDB при этом недоступен. Например, потому что программу вы отлаживаете под MacOS или FreeBSD, а в этих системах традиционно используется отладчик LLDB. Лично я в последнее время склонен отдавать предпочтение LLVM-стэку (CLang, LLDB) даже на Linux-машинах, где по дэфолту используется GNU-стэк (GCC, GDB). В LLDB все еще есть кое-какие шероховатости. Но команды структурированы намного лучше, чем в GDB, а шероховатости со временем все равно поправят. Так или иначе, в процессе изучения LLDB я составил шпаргалку по основным его командам, которой и хочу сегодня с вами поделиться.
Недавно мы научились собирать FreeBSD из исходных кодов. Этих знаний достаточно, если вы хотите просто попробовать самые свежие фичи системы или оптимизировать FreeBSD под конкретное железо. Но если вы собираетесь как следует порыться в кишках системы, дабы лучше разобраться в ее работае, или даже что-то изменить в ней, необходимо уметь цепляться к системе отладчиком. Да и если вы админите сервера под управлением FreeBSD, знания о том, как анализировать корку упавшего ядра, пожалуй, будут не лишними.
Ранее в заметке Основы использования отладчика WinDbg мы узнали, как можно отлаживать приложения под Windows. Теперь настало время познакомиться с отладчиком gdb, который позволяет делать все то же самое под Linux и другими *nix системами. Благодаря этой заметке вы узнаете, как при помощи gdb ставить брейкпоинты и смотреть значения локальных переменных, анализировать coredump’ы и вот это все.
Поговорим об отладчиках для Microsoft Windows. Их существует довольно много, вспомнить хотя бы всеми любимый OllyDbg, некогда популярный, но в настоящее время практически умерший SoftIce, а также Sycer, Immunity Debugger, x64dbg и бесчисленное количество отладчиков, встроенных в IDE. По моим наблюдениям, WinDbg нравится далеко не всем. Думаю, в основном это связано с командным интерфейсом отладчика. Любителям Linux и FreeBSD, бесспорно, он пришелся бы по душе. Но закоренелым пользователям Windows он кажется странным и неудобным. А тем временем, по функционалу WinDbg ничем не уступает другим отладчикам. Как минимум, он точно нечем не хуже классического GDB или там LLDB. В чем мы сегодня с вами и убедимся.
Взаимодействие процессов в Erlang происходит путем обмена сообщений. И хотя сообщения в Erlang дешевы, они не бесплатны. Бездумная посылка сообщений неправо и налево может привести не только к существенному замедлению работы всего приложения, но и к его аварийному завершению.
Как мы обычно отлаживаем программу, если она не работает? Традиционный и самый простой способ — напичкать ее отладочным выводом, запустить, и посмотреть, что происходит. Чего уж греха таить. Однако в Erlang вы можете с легкостью сделать практически то же самое, не трогая исходный код программы, с помощью трассировщика dbg.
Не понимаю, почему я раньше так его боялся. Недавно попробовал запустить, почитал справку и «карманный справочник», все понял и начал пользоваться. Принципы абсолютно те же, что и в других отладчиках. Думаю, тут мне весьма помог опыт работы с OllyDbg.
