Введение в postmortem debugging

[@dimag0g]

А есть что-нибудь кроссплатформенное? Сам пользуюсь DrMingw, но он только под Windows.

[@gribozavr]

На *nix просто нужно разрешить создание core файлов. Остальное система сделает сама.

[@dimag0g]

А чем можно из core файлов извлечь стек вызовов и связать его с символами из исходников?

[@gribozavr]

$ gdb a.out core
GNU gdb (GDB) 7.0.1-debian
Copyright © 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<www.gnu.org/software/gdb/bugs/>...
Reading symbols from /tmp/a.out...done.

warning: Can't read pathname for load map: Ошибка ввода/вывода.
Reading symbols from /lib/libc.so.6...Reading symbols from /usr/lib/debug/lib/libc-2.10.2.so...done.
(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols from /usr/lib/debug/lib/ld-2.10.2.so...done.
(no debugging symbols found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Core was generated by `./a.out'.
Program terminated with signal 11, Segmentation fault.
#0 0x000000000040049d in main () at a.c:3
3 *((int *) 0) = 0;
(gdb)

[@gribozavr]

А стек вызовов — как обычно — командой bt.

[@vilgeforce]

WinDbg, конечно, хорош… Но неудобен ужасно для отладки :-(

[@Sicness]

А что, он один умеет анализировать эти dump фалы? Или они специфичны, как почти всё от microsoft…

P.S.
Спасибо за статью!

[@crashdumper]

Студия умеет отрывать дампы, но опять-же с сервером символов работает хуже.

[@crashdumper]

Ещё вспомнил, формат минидампов вроде открытый и в сети можно найти его описание, а вот фуллдамп которы делает система при синем экране смерти — закрытый формат.
И вообще минидамп — это просто в удобной форме сделаная информация из *.map и *.cod файлов (посмотрите настройки проекта, там есть опции создания этих файлов, затем гляньте их содержимое, всё станет ясно)

[@crashdumper]

Действительно, для отладки не очень хорош, чаще всего его используем для разбора дампов и удаленной отладки. Плюс — он лучше чем студия заточен на руботу с сервером символов, с различными тулзами типа Microsoft Application Verifier (для поиска утечек хендлов). Хотя я возможно уже что-то упастил ибо я на данный момент больше управленец чем прораммер.

[@SilentBob]

Да ладно, это дело привычки. Стоит пару дней поработать и становится нормально. Еще пару — и не понимаешь, как дил прежде: многие вещи просто по-другому не сделать.

* У windbg нет такого красивого интерфейса, но зато он компактен. Его можно скопировать на шару и запускать оттуда без установки.

* Низкоуровневый способ отладки. Просмотр служебной информации Windows: кто создал поток, кто выделил память, сколько времени какой поток работал.

* Можно писать небольшие скрипты: «остановиться в этом месте и проверить значение переменной. Если оно меньше 10 идти дальше, иначе вывести в консоль. А если равно 0 то перейти в интерактивный режим».
А можно сделать и большой плагин, автоматизирующий расследование краша программы.

Одним словом, VS — это примерно 1% от функционала. Он постоянно обрастает новыми возможностями, но до windbg им далеко.

[@crashdumper]

Вот-вот.
У меня был опыт расследования утечек хендлов при проведении определенной операции в программе, т.е. я смотрел кол-во хендлов, делал операцию, ещё раз смотрел кол-во хендлов и оно не совпадало. Обычным дебагером такое нельзя было расследовать, т.к. дело было в том что во время выполнения действия в процесс подгружалась Dll, хендлы текли в ней, по завершению действия Dll выгружалась и досвидания. только связка WinDbg + Microsoft Application Verifier помогла найти все стеки создания и удаления хендлов, данные были сопоставлены и выявлен модуль в котором утечка, модуль был выгружен, но это уже было делом техники найти от него pdb и выдрать данные (а-ля map файл)

[@vilgeforce]

Я так и не нашел способ переопределения команд StepIn и StepOver. Учитывая, что я использую еще 2 отладчика учить кнопки еще и для третьего — действительно неудобно. Помогло только подключение windbg к IDAPro, там уже назначено на «правильные» клавиши.

[@crashdumper]

Да я не агитирую за использование WinDbg в качестве отладчика на каждый день. Каждий инструмент хорош для своего дела, например гайку можно открутить разводным ключем, накидным ключем, рожковым ключом, торцевым ключем, всё зависит от того что за гайка, как к ней подлезать и чем будет удобно работать. Я всем руками за, если мои программеры хорошо владеют отладчиком студии, WinDbg и Ida

[@arilou_camper]

Пишите еще. По зову судьбы и старому желанию, последние полгода программирую на С++. Ваши статьи помогают набрать инструментарий и знания для серьезной работы.

[@crashdumper]

Постараюсь. Я по зову судьбы последние 2 года имею к написанию кода посредсвенное отношение, да и если приходится писать/смотреть код то в основном на C#. Данная статья, в совокупности со статьей про разворачивание сервера символов, является больше статьей на расширение рабочего пространства разработчиков и подстегивания их использовать инструментарий повышающий качество продукта. В ближайшем будущем постараюсь сделать статьи по развертыванию сервера индексации исходников и по удаленной отладке (в контексте взаимодействия с отделом качества)

[@arilou_camper]

Самое смешное, что год назад я говорил «все, большое программировать не буду» =) И