> On Jan 1, 2016, at 6:54 PM, SevenBits <sevenbitst...@gmail.com> wrote: > > Setting an exception breakpoint didn’t help; the app crashes anyway, leading > me to believe that the problem either a) is not an uncaught exception or b) > it is an exception, but occurs before the ObjC runtime is initialized.
It’s not an exception in the Obj-C or C++ sense; it’s a _CPU exception_, which is usually called a crash. (Note "Thread 0 Crashed” at the top of the main thread’s backtrace.) The log also tells you that the crash is an EXC_BAD_ACCESS, which is triggered by accessing an invalid memory address. Most importantly, the crash is in objc_msgSend and the log’s App-Specific Info section says "objc_msgSend() selector name: respondsToSelector:”. 99.9% of the time, a crash in objc_msgSend means a bogus Obj-C object pointer is being messaged; usually that’s a pointer to a dealloced object, although it could be a garbage pointer retrieved from an ivar of a dealloced object. Since the caller is -[NSApplication updateWindows], it’s a pretty good bet that the offending pointer is to an NSWindow. The usual tool for diagnosing calls to dealloced objects is NSZombies. You can turn this on in the Diagnostics tab of the Run page of the scheme editor. —Jens _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
