1

I use Google Breakpad for crash reporting a C++ app on Mac and Windows. On both platforms, Breakpad works by registering a handler for uncaught exceptions. That handler is triggered by most anything that would normally crash a process, e.g. dereferencing a null pointer.

But now I have a scenario where the handler isn't being invoked and the process crashes to the OS crash reporter. It's 100% reproducible, but I can't debug it because attaching a debugger to the process preempts the uncaught exception handler.

What techniques (other than copious printfs) can help me trace where the code flow is going if not to my handler? I think I'd like some IDE setting to let my debugger (Visual Studio and/or Xcode) step past the null pointer dereference and into the C++ runtime's handler code. But other techniques would be welcome too.

I have a minimal reproduction of my problem scenario here: https://bugreports.qt.io/browse/QTBUG-50061

Thomas Weller
  • 55,411
  • 20
  • 125
  • 222
Chris Dolan
  • 8,905
  • 2
  • 35
  • 73
  • Debug prints are often the most reliable method of tracing a failure. Personally, that's all I use to debug. – owacoder Dec 22 '15 at 22:21
  • @owacoder - agreed, and that's how I've been troubleshooting prior to this problem. But now I've got a crash scenario that never seems to enter my handler so I don't even know where to put a printf! I'd love to see where the program goes after the crash if not into my code. – Chris Dolan Dec 22 '15 at 22:28
  • Just a note to visitors to the future: it looks like this issue in QTBUG-50061 is related to the native code generation for JavaScript implementation that somehow messes up the stack for exception handling, so the exception handler is never invoked. The workaround was just to turn off JIT. I never did figure out a better debugging tool than many, many printfs... – Chris Dolan Feb 16 '16 at 20:47

0 Answers0