Breakpad on iOS doesn't catch exceptions that are re-thrown

[GoogleCodeExporter]

Breakpad on iOS handles most exceptions well, but if it's rethrown you just get 
something like:

0x39336564   [libobjc.A.dylib]   + 0x00003564]  _cache_getImp
0x39336f87   [libobjc.A.dylib]   + 0x00003f87]  lookUpMethod
0x393381d5   [libobjc.A.dylib]   + 0x000051d5]  class_respondsToSelector
0x314a2603   [CoreFoundation]    + 0x000c2603]  objectIsKindOfClass
0x314a235b   [CoreFoundation]    + 0x000c235b]  __handleUncaughtException
0x3933ba63   [libobjc.A.dylib]   + 0x00008a63]  _objc_terminate()
0x38d88079   [libc++abi.dylib]   + 0x00001079]  safe_handler_caller(void (*)())
0x38d88112   [libc++abi.dylib]   + 0x00001112]  std::terminate()
0x38d89597   [libc++abi.dylib]   + 0x00002597]  __cxa_rethrow
0x3933b9cf   [libobjc.A.dylib]   + 0x000089cf]  objc_exception_rethrow
0x313e8f1f   [CoreFoundation]    + 0x00008f1f]  CFRunLoopRunSpecific
0x313e8d47   [CoreFoundation]    + 0x00008d47]  CFRunLoopRunInMode
...

Which doesn't really give any clues as to what's going on. It would be good if 
we can find a way to get rich handling for this case too.

Original issue reported on code.google.com by [email protected] on 19 Sep 2013 at 9:39

[GoogleCodeExporter]

Doesn't std::set_terminate help with this?

Original comment by [email protected] on 4 Jun 2014 at 4:10

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

 Unfortunately no. std::terminate is only called when there is not exception handler.

 When there is a catch/rethrow of a C++ exception, the interesting stack is destroyed when the code in the catch block is executed, and it is then too late to get anything interesting.

Original comment by [email protected] on 4 Jun 2014 at 4:17

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Why can't you install a std::terminate handler and do what _objc_terminate() 
does?  In the callstack above, the object is clearly an objc exception which 
should have the call stack.  No? Am I missing something?

Original comment by [email protected] on 12 Jun 2014 at 5:11

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Because the code looks like something like this:

try {
} catch(e) {
  // HERE
  throw e;
}

The terminate is called at the HERE place in the stack. The stack where the 
original exception has been called doesn't exist anymore.

Original comment by [email protected] on 13 Jun 2014 at 4:18

• Added labels: ****
• Removed labels: ****