Russian Qt Forum

Задача такая:
  Есть кутевая программа с отладочной информацией, к-ая установлена у нескольких тестеров под win и linux. Естественно  :D она иногда падает. Надо написать кутевый класс, к-ый отслеживает падения средствами ОС, собирает информацию о крэше ( стек вызовов в момент падения и т.д. ) и делает с этой инфой что-то полезное: например пишет в лог или отсылает по мылу разработчику.
  Под линух схема более менее понятная:  устанавливаем обработчик сигналов, в нем вызываем gdb и юзаем его команды (backtrace и т.д.). А что делать под виндой? Понятно, что там должно быть что-то похожее. У кого-нить есть какие-то идеи или наработки?

Ты какой компилятор используешь?
Если MSVC то используй Dr.Watson и WER (http://www.microsoft.com/whdc/maintain/StartWER.mspx)
В случае с GCC  может помочь Dr.MinGW.

я у себя делал так:

в main в самом начале писал вот эти две строчки:
    _CrtSetReportHook(MyReportHook);
    SetUnhandledExceptionFilter(MyFilter);

MyFilter - пишет в лог информацию о креше (стека вызовов нет) + системную информацию о компьютере
архивируются все файлы *.log и отправляются по почте
вместо стека вызовов пишу все вызовы в trace.log

есть еще отдельный класс для уведомления о событиях в программе через jabber


если что-то интересно, могу прислать куски кода

2 burunduk: Спасибо за инфу  :D
Нашел как получить стек вызовов в винде: http://www.codeproject.com/threads/StackWalker.asp :) Правда, сцуко, с юникодом  не дружит, пришлось #undef UNICODE вставлять. А так вроде работает, даже номера строк в коде выдает.
Счас попробую в ExceptionFilter вставить.

добавлено спустя 1 час 28 минут:

 Работает :) Осталось сделать реализацию под линух. Да, кстати, не догнал нах юзать _CrtSetReportHook: без него все прекрасно работает.

можно забить на него
я вставлял его для того чтобы в дебаг версии Q_ASSERTы тоже перехватывались. И подозреваю что это только для win

ИМХО такой подход - путь в никуда.
Крашрепорт, как правило, ничем не помогает разработчику, тем более юзеру.
По моему, надо вещь под дебагером нормально вылизать сначала, на тех примерах, на которых у тестеров происходит падение.
Ибо такого рода репорты - лишний геморой для всех без исключения.

когда тестеров просто нету такой подход лучше чем ничего;
по детальным логам уже можно локализовать проблему, а дальше даже если не помогло - можно самим потестить данный участок кода

Так как раз тестеры таки и есть :)

Пардон, недосказал, нормальных тестеров как раз и нету :) В моем случае есть несколько пользоватей, к-ые работают с прогой в производственном режиме. Прога обрабатывает очень большие объемы данных, как правило около сотни гигов, иногда терабайты, и соответсвенно работает несколько часов (суток). Так что воспроизведение багов довольно проблематично.

а, вот даже как...
ну тогда конечно, хотя бы с дампом...