Hi Bruce, Many thanks for the reply. Unfortunately that's a little trickier than it sounds - my app has around 200,000 lines of code. :) That said, I know that the trigger is page layout mode but I've already been through the page layout code (and the page-layout-switching code) several times checking for an over-release, and there's nothing obvious in there. Given that NSZombieEnabled isn't coming up with anything, I'm thinking it could be an un-initiated variable somewhere, but again I've been through the classes that seem to be part of the trigger and have found nothing untoward.
It's particularly tricky as this crasher does not affect many users and I've only now been able to reproduce it, thanks to a user sending me a problem file, after three months of knowing it was lurking from reports generated from my app's built-in crash reporter. It seems to be down to a particular way a table is arranged in an NSTextView in my page layout code, but even then it doesn't always happen, and of course the page layout trigger may be a red herring. Today I separated the page layout code out into a separate Xcode project, placed all of the code and the problem document that seemed to be triggering the crash into the separate app... And of course it refused to crash. The debugging continues... Thanks again! All the best, Keith --- On Wed, 2/16/11, Bruce Cresanta <cresa...@me.com> wrote: > From: Bruce Cresanta <cresa...@me.com> > Subject: Re: Tracking a EXC_BAD_ACCESS when zombies don't work > To: "Keith Blount" <keithblo...@yahoo.com> > Cc: cocoa-dev@lists.apple.com, "Sean McBride" <s...@rogue-research.com> > Date: Wednesday, February 16, 2011, 6:52 PM > A big clue is in your backtrace: > > #261968 0x98d06f38 in CFRelease > #261969 0x98d06f38 in CFRelease > #261970 0x98d06f38 in CFRelease > #261971 0x98d33c6d in > _CFAutoreleasePoolPop > #261972 0x9867d0aa in > NSPopAutoreleasePool > #261973 0x9867cfd2 in -[NSAutoreleasePool > drain] > #261974 0x986c4596 in > _NSAppleEventManagerGenericHandler > #261975 0x91450f58 in > aeDispatchAppleEvent > #261976 0x91450e57 in > dispatchEventAndSendReply > #261977 0x91450d61 in > aeProcessAppleEvent > #261978 0x9519d389 in > AEProcessAppleEvent > #261979 0x93b9a9ca in _DPSNextEvent > #261980 0x93b99fce in -[NSApplication > nextEventMatchingMask:untilDate:inMode:dequeue:] > #261981 0x93b5c247 in -[NSApplication > run] > #261982 0x93b542d9 in NSApplicationMain > #261983 0x0003513a in main at main.m:23 > > > > ////////////// > #261971 0x98d33c6d in > _CFAutoreleasePoolPop results in EXC_BAD_ACCESS when > you release a variable marked as > autorelease. Go back through your code and > make sure you manually haven't released an autoreleased > variable. > > Bruce > > > > > > On Feb 16, 2011, at 11:27 AM, Keith Blount wrote: > > > And the backtrace doesn't help either: > > > > #261968 0x98d06f38 in CFRelease > > #261969 0x98d06f38 in CFRelease > > #261970 0x98d06f38 in CFRelease > > #261971 0x98d33c6d in > _CFAutoreleasePoolPop > > #261972 0x9867d0aa in > NSPopAutoreleasePool > > #261973 0x9867cfd2 in > -[NSAutoreleasePool drain] > > #261974 0x986c4596 in > _NSAppleEventManagerGenericHandler > > #261975 0x91450f58 in > aeDispatchAppleEvent > > #261976 0x91450e57 in > dispatchEventAndSendReply > > #261977 0x91450d61 in > aeProcessAppleEvent > > #261978 0x9519d389 in > AEProcessAppleEvent > > #261979 0x93b9a9ca in _DPSNextEvent > > #261980 0x93b99fce in > -[NSApplication > nextEventMatchingMask:untilDate:inMode:dequeue:] > > #261981 0x93b5c247 in > -[NSApplication run] > > #261982 0x93b542d9 in > NSApplicationMain > > #261983 0x0003513a in main at > main.m:23 > > _______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
