Re: EXC_BAD_ACCESS in a Core Data application
Re: EXC_BAD_ACCESS in a Core Data application
- Subject: Re: EXC_BAD_ACCESS in a Core Data application
- From: Kyle Sluder <email@hidden>
- Date: Fri, 4 Sep 2009 10:21:52 -0700
On Fri, Sep 4, 2009 at 9:35 AM, Ian Piper<email@hidden> wrote:
> I suppose that when I close the window it is released, so when I try to open
> it again there is nothing to open.
Yep. Common pitfall.
> 1. Why does a window default to having this option checked? It seems odd,
> since the auto-generated code seems to look after memory management and
> therefore this is more or less guaranteeing a problem.
History? It's rare that any app actually takes advantage of Release
When Closed and/or Visible At Launch nowadays. I've filed a Radar
asking that these be hidden, or at least their defaults changed.
> 2. What is the best strategy for tracking down this kind of problem? I tried
> using Instruments and that indeed showed a memory leak at the point that I
> tried to load this window, but I couldn't see how to use this information to
> zero in on the root cause.
NSZombie. Setting NSZombieEnabled="YES" in your environment variables
will cause released objects to turn into zombie instances rather than
being deallocated. Then when you message them they will log to the
console.
On Snow Leopard, use the Zombies Instruments.app template. It's on
the Run > Run with Performance Tool menu. It enables zombies and
presents them in a very nice interface.
> 3. Is there a way to attach a breakpoint to a UI action (such as clicking on
> the File menu, which is where the freeze happened)?
It would require some serious conditional breakpoint actions.
> 4. Without wishing to open any cans of worms, a Core Data application like
> this seems like a sensible place to use GC. Is that right?
There have been known GC incompatibilities in Core Data (specifically
with the SQLite store) in the past. These are obviously bugs, and if
you encounter any you should file a bug report. Overall GC seems as
stable with Core Data as it is with other technologies.
--Kyle Sluder
_______________________________________________
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