See [https://bugzilla.mozilla.org/show_bug.cgi?id=163260 bug 163260].
== Gecko 1.8 ==Since there isn't a whole lot of code The basic problem we have is thatalmost every call into Apple's using Cocoa in Gecko 1framework (C or Obj-C) could potentially throw an Obj-C exception and unwind our stack with nasty consequences.8Sometimes the browser crashes, sometimes it might be best to to write macros just appears to wrap any XPCOM entry point that calls cocoahave lost its mind, start to finishand theoretically there could be security consequences. NS_OBJC_EXCEPTION_CATCHER_START This is because we have no handlers in place now and as the stack unwinds code gets skipped and _END, for exampleC++ temporary objects do not get their destructors run.
AnotherYou can read more about it in the bug, eviler approach but the conclusion we came to is that we need to override NSException's initWithName:reason:userInfo: method to instead call some sort of assertion, and then return nil. This of course bypasses the entire ObjC wrap all calls into Apple frameworks with Obj-C exception system, and will horribly, horribly break any code that depends upon actually handling ObjC exceptionshandlers. There might still some merit in the idea of posing as NSException, perhaps to override -raise?
== Gecko 1.9 ==I have checked in a set of macros for doing that, see this file:
Mac OS X 10.3 brought new exception handling support. It's possible that setjmp and longjmp may no longer be used for some parts of the exception system, which now appears to be in the compiler, at least partially. Some parts of the exception handling are still using setjmpmozilla/xpcom/base/longjmp, obviously, because stack smashing is still occurring. Need to look into exactly what's safe and what's not. We may end up in the same boat as on branch, unfortunatelynsObjCExceptions.h
As far as I've seenBefore you start doing anything, Apple documents please read through every line of that file and make sure you understand what exceptions can get thrownall of it is for. We really should just exit the browser with If you don't understand anything please ask me on email or irc. It wouldn't be very awesome if you posted a nonzero exit code when we catch an unhandled ObjC exceptionbunch of work and had to do it all over again. --[[User:Cbarrett|Cbarrett]] 15:33, 14 September 2007 (PDT)
Another thing to read over is nsAppShell.mm. I have done the work for nsAppShell.mm already and checked it in. Make sure you understand why I made the choices I did there, and again ask if you are unclear about anything. When wrapping calls in a method, the first choice you'll have to make is whether to wrap specific calls or the whole method impl. Which one you pick is usually a matter of cleanliness. If there is a big method with a single Apple framework call in it, you might just want to wrap that specific call. Your choice of macros are these: NS_OBJC_TRY_IGNORENS_OBJC_TRY_ABORT NS_OBJC_TRY_EXPR_NULLNS_OBJC_TRY_EXPR_ABORT The ones that contain EXPR are for expressions - for example: foo == setjmp/longjmp not entirely fatal? ==NS_OBJC_TRY_EXPR_ABORT([bar doSomething]); It should They wrap an expression that returns a value. The other macros don't. They'd be noted for something like this: NS_OBJC_TRY_ABORT([bar doSomething]); The macros that as long as include ABORT will kill the stack is able app if they catch an exception, you will almost always want to be unwound properly once use these. It saves a lot of time if we return don't have to C++, things should be OKthink about recovery strategies for calls. ItIn order to code for recovery you's still unclear why d have to understand something about the context of the crashes code you are happening working in . If we start seeing exceptions killing the app it'll be easy to go back and code the first place, so perhaps a different NSExceptionHandler mask, using an NSExceptionHandler delegate, or calling NSSetUncaughtExceptionHandler will allow us calls that are throwing for recovery. That probably won't happen and if it does it'll probably be just 1-2 calls we need to handle ObjC exceptions in a more graceful mannernot abort on. More coming...- block macros- identifying apple framework calls- non-.mm files- whitespace- including nsObjCExceptions.h -Josh Aas
