Whenever I hit an Obj-C exception (in bug 1257765 or elsewhere), it's followed by a crash in a random location. I believe Firefox is throwing away its C++ stack without properly running RAII destructors, and then pretending everything is fine. I don't remember why I believe this. (Is this true? Has it been true ever since bug 486574 landed?)

I attached an example that's unrelated to bug 1257765, just to demonstrate that it seems to be a wider problem. In this case my extension <https://github.com/MozillaSecurity/funfuzz/tree/master/dom/extension> is violating some rule about keypresses, I guess, but this shouldn't lead to a crash in JIT code!

(In reply to Jesse Ruderman from comment #0) > Whenever I hit an Obj-C exception (in bug 1257765 or elsewhere), it's > followed by a crash in a random location. ... nice. > I believe Firefox is throwing away its C++ stack without properly running > RAII destructors, This appears to be true, according to http://mirror.informatimago.com/next/developer.apple.com/releasenotes/Cocoa/Objective-C++.html#exceptions > and then pretending everything is fine. I don't remember > why I believe this. (Is this true? Has it been true ever since bug 486574 > landed?) I don't recall this issue ever being mentioned in any reviews for patches to exception-protected methods. It's definitely possible that we completely missed it all this time.

On the other hand, there's this about 64 bit executables: https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Exceptions/Articles/Exceptions64Bit.html#//apple_ref/doc/uid/TP40009044-SW3 > In 64-bit processes, Objective-C exceptions (NSException) and C++ exception are > interoperable. Specifically, C++ destructors and Objective-C @finally blocks are > honored when the exception mechanism unwinds an exception.

We compile our code with -fno-exceptions and we do not expect exceptions to be thrown across any gecko code. We should make sure that any objc exceptions are caught/handled before entering gecko code, or are suitably fatal.

An excerpt from a comment of mine in bug bug 1257765 explaining what we do now: When the exception is thrown it should be caught by these macros which wrap the contents of 'OSXNotificationCenter::ShowAlertWithIconData': NS_OBJC_BEGIN_TRY_ABORT_BLOCK_NSRESULT; ... NS_OBJC_END_TRY_ABORT_BLOCK_NSRESULT; These macros are defined in 'xpcom/base/nsObjCExceptions.h': #define NS_OBJC_BEGIN_TRY_ABORT_BLOCK_NSRESULT @try { #define NS_OBJC_END_TRY_ABORT_BLOCK_NSRESULT } @catch(NSException *_exn) { \ nsObjCExceptionLog(_exn); \ } \ return NS_ERROR_FAILURE; This will catch the exception, log it, try to log stack info only if in a debug build, and return NS_ERROR_FAILURE from the C++ method.

Can someone take this and look at patching it?

(In reply to Al Billings [:abillings] from comment #8) > Can someone take this and look at patching it? Comment 7 suggests we're already patched unless some code is missing the exception-wrapper macros. Jesse: how does your second test case behave with Josh's patches from bug 1257765?

Markus, could you look into fixing this? Thanks.

I'm investigating what's going on here.

OK, yeah, the same rules as always apply: exception handling across functions that are compiled as ObjC++ works, and in 64 bit builds it will correctly call destructors of objects on the stack. Exceptions must not bubble up to C++ callers. So all we need to do is make sure we have exception guards in all functions/methods defined in ObjC++ files that can be called by non-ObjC++ callers. Jesse, is there anything you want to be done in this bug specifically? Do you know of any ways to trigger ObjC exceptions that are not covered by bug 1257765? (Can you CC me on that one?)

Resolving as worksforme per last comment. Jesse, please reopen or file a new bug if there is some other way (other than bug 1257765) to trigger this. Thanks.