Page MenuHomePhabricator

Feature: Google Breakpad Crash Reporting
Closed, WontfixPublic

Description

Aim is to better reproduce application crashes by means of generated minidumps / stack traces in the event of an application crash.

  • Generate a breakpad exception handler
  • Initiate an out-of-process exception server that dumps the stackt race

Event Timeline

First working, windows only prototype implementation pushed:
http://mitk.org/git/?p=MITK.git;a=commit;h=bbe61ec8222aa990d64d6ed7ab860c6fd1811d8b

OutOfProcess dump does not permanently use a separate process, but only temporarily.

Current implementation totally relies on the sample crash_generation_server project.

To reproduce:
0. Have breakpad built with vs2008 and /MD runtime linkage (in source build).

  1. Enable MITK_USE_BREAKPAD_CRASH_REPORTING in cmake and set MITK_BREAKPAD_SRC_DIR to myBreakpadDir/src.
  2. Have C:\dumps directory created.
  3. Run QtAppExample until it purposely crashes.
  4. See the minidump file in C:\dumps\

To load a dump file:

  • Simply place the file in you ./bin/debug directory along all *.pdb symbol files.
  • Run empty Visual Studio, Choose "Open Solution" and point to the dump file.
  • Run the debugger as if you wanted to start a new debugging session.

OutOfProcess dump does not permanently use a separate process, but only temporarily.

not sure about that anymore.

completed implementation and documentation.

See mitkBreakpadCrashReporting.h for documentation.

Currently known issues:

  • Implemented and tested only for Windows, although there should be very small changes required for other OSes. Should be separate ticket.
  • No proper CMake implementation, no superbuild integration. Should be separate ticket.
  • Automatic shutdown of the CrashReportingServer now takes place, if there was at least once a client connection. The mitkCrashReportingServer could be enhanced with a qt event loop for pro-active while being idle for some time. Don't know how to deal with simple moc-ing of 'main.moc' by means of QT4_WRAP_CPP.
  • QtSampleApp project currently abused for testing - should be reverted before merge to master.

Waiting for feedback before merging.

Just saw this bug closed. Until it is merged I suggest leaving it open so people find it and its status is reflected properly.

We can leave this open but remove the blockers, as it does not block them any more.

By now I put quite some effort into integrating this in a more MITK like fashion. Before I proceed, I'd like to get some feedback by Sascha.

In branch personal/maleike/breakpad, I now succeeded in:

  • adding a superbuild level switch MITK_USE_BREAKPAD
  • pulling Breakpad from SVN source
    • this should be replaced by a tarball like ITK etc. when integrated
  • compiling the project on Windows and Linux
  • adapting the MITK BreakpadCrashReporting module to work on Windows and Linux
  • implementing two unittests: one crashing, the other one checking existence of a crash dump

Now I could imagine some locations where we could initialize the crash-dump-server:

  • in mitkWorkbench / CoreApp directly
    • would be early
  • in some plugin activator class?
    • everything using the plugin would automatically get dump functionality - in the module activator
    • everything using the module would automatically get dump functionality

What would be the best way to proceed?

New remote branch pushed: bug-13351-breakpad-module-2012-12

After talking with Daniel, we decided to rebase the existing commits based on the 2012.12 release.

Since the commits for the Breakpad module were contained in branches which were not based on the release tag and also contained other merges, I had to cherry-pick a few and rebase the recent ones.

I am not sure if the MINT branches containing any of the Breakpad commits are supposed to be merge back to MITK master any time. If they are, we will have to look out for merge issues with the newly created branch.

The newly created branch (see comment above) contains only the Breakpad commits and is based on the v2012.12.0 tag.

TODOS:

  • Remove Qt dependency from the module
  • Create a source tarball instead of pulling from SVN
  • Build the module statically
  • Use MITK_INSTALL macro for the crash server and test packaging
  • Check if fork() under Linux may use too many resources
  • Integrate it into the mitkWorkbench

This bug could not be fixed for release 2013-06. Setting target milestone to next release

New remote branch pushed: bug-13351-breakpad-module

(In reply to Sascha Zelzer from comment #9)

TODOS:

  • Remove Qt dependency from the module

Done.

  • Create a source tarball instead of pulling from SVN

Tarball needs to be uploaded.

  • Build the module statically

Done.

  • Use MITK_INSTALL macro for the crash server and test packaging

Done.

  • Integrate it into the mitkWorkbench

Done.

Open ToDos are:

  • Target for dumping symbols on linux: To be able to read the stack trace dumped from breakpad we need to have the debugging symbols in a text-formated debugging symbol file (see https://code.google.com/p/google-breakpad/wiki/LinuxStarterGuide ). I created a script where you only have to give the binary path as parameter to create debugging symbols text files. It would be nice if we would create a target "DUMPING_SYMBOLS" which can be build on demand and creates the debugging symbols text file. Needs to be discussed with Sascha.
  • On linux there is currently still a problem with crash dump generation: Sometimes the processes get in a wait state where each process waits for the other process to react. I couldn't figure out why this is sometimes happening. It doesn't occure everytime. This can easily be reproduce when executing the test mitkBreakpadCrashReportingDumpTest several times. The test is currently deactivated on linux until the problem is located and fixed. The problem seems to occure in the class linux_ptrace_dumper.cc in the method SuspendThread(pid_t pid).

Current release is finished. Resetting target milestone

User dsaruji has pushed new remote branch:

bug-13351-latest-version-breakpad
  • tarball includes a CMakeLists.txt that is not part of the original source. We should keep that separate in the MITK source tree and patch/copy it in after download to keep the source in the original state
  • there are linker errors on Fedora 20 / gcc 4.8:

Linking CXX executable minidump_stackwalk
libprocessor.a(stackwalker.cc.o): In function `google_breakpad::Stackwalker::StackwalkerForCPU(google_breakpad::SystemInfo const*, google_breakpad::MinidumpContext*, google_breakpad::MemoryRegion*, google_breakpad::CodeModules const*, google_breakpad::StackFrameSymbolizer*)':
stackwalker.cc:(.text+0xa74): undefined reference to `google_breakpad::StackwalkerPPC64::StackwalkerPPC64(google_breakpad::SystemInfo const*, MDRawContextPPC64 const*, google_breakpad::MemoryRegion*, google_breakpad::CodeModules const*, google_breakpad::StackFrameSymbolizer*)'
collect2: error: ld returned 1 exit status

  • Superbuild default is ON, do we want that?

User engelm has pushed new remote branch:

bug-13351-breakpad-again

User engelm has pushed new remote branch:

bug-13351-breakpad-another-time
kislinsk added a subscriber: kislinsk.
This task was automatically closed because it wasn't updated at least since July 2016 (over 2 years). Please re-open this task if you think that it is still relevant. This most probably means that you will resolve it.