• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Tracking a EXC_BAD_ACCESS when zombies don't work
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Tracking a EXC_BAD_ACCESS when zombies don't work


  • Subject: Re: Tracking a EXC_BAD_ACCESS when zombies don't work
  • From: Keith Blount <email@hidden>
  • Date: Wed, 16 Feb 2011 11:17:27 -0800 (PST)

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 <email@hidden> wrote:

> From: Bruce Cresanta <email@hidden>
> Subject: Re: Tracking a EXC_BAD_ACCESS when zombies don't work
> To: "Keith Blount" <email@hidden>
> Cc: email@hidden, "Sean McBride" <email@hidden>
> 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 (email@hidden)

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:

This email sent to email@hidden

  • Follow-Ups:
    • Re: Tracking a EXC_BAD_ACCESS when zombies don't work
      • From: "Sean McBride" <email@hidden>
References: 
 >Re: Tracking a EXC_BAD_ACCESS when zombies don't work (From: Bruce Cresanta <email@hidden>)

  • Prev by Date: Re: Tracking a EXC_BAD_ACCESS when zombies don't work
  • Next by Date: Re: Tracking a EXC_BAD_ACCESS when zombies don't work
  • Previous by thread: Re: Tracking a EXC_BAD_ACCESS when zombies don't work
  • Next by thread: Re: Tracking a EXC_BAD_ACCESS when zombies don't work
  • Index(es):
    • Date
    • Thread