Типичный отладчик, такой как WinDbg или LLDB, позволяет выполнять программу шаг за шагом, просматривая значения переменных, создавая брейкпоинты, и так далее. Reverse debugging — это когда вы можете делать все то же самое, но не в прямом порядке, а в обратном, как бы «назад во времени». Сегодня мы познакомимся с двумя способами reverse debugging’а в Linux. Вероятно, эти способы работают и на других платформах, но я не проверял.

Бывает, что нужно отладить программу, а GDB при этом недоступен. Например, потому что программу вы отлаживаете под MacOS или FreeBSD, а в этих системах традиционно используется отладчик LLDB. Лично я в последнее время склонен отдавать предпочтение LLVM-стэку (CLang, LLDB) даже на Linux-машинах, где по дэфолту используется GNU-стэк (GCC, GDB). В LLDB все еще есть кое-какие шероховатости. Но команды структурированы намного лучше, чем в GDB, а шероховатости со временем все равно поправят. CLang же генерирует намного более понятные сообщения об ошибках, чем GCC. Так или иначе, в процессе изучения 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.

Что ни говори, а отладочный вывод был и остается одним из самых простых и часто используемых способов отладки. Но как прикажите использовать его в Haskell при написании чистых функций? Временно оборачивать функцию в монаду IO, а по завершении отладки возвращать код к прежнему состоянию? Разумеется, нет!

Решил вот написать свой HTTP сниффер. Не то, чтобы существующие решения, всякие там FireBug, Wireshark, tcpdump и urlsnarf, плохо работали. Просто какие-то они не совсем удобные или не всегда делают то, что мне действительно нужно.