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: Eric Hermanson <email@hidden>
- Date: Fri, 04 Sep 2009 12:48:00 -0400
In my experience this can happen for at least 3 reasons.
1. Over-releasing an object, as you state.
2. Sending a message to an object that has already been released (i.e.
deallocated).
3. Attempting to access or return a local variable that has not been
initialized (although you may get a segmentation fault instead of a
BAD_ACCESS, I can't remember). For example,
- (BOOL)someMethod
{
BOOL returnValue;
// code in the method that never sets the returnValue to anything
return returnValue; // this is bad.
}
On Sep 4, 2009, at 12:35 PM, Ian Piper wrote:
Hi all,
I have been putting together a Core Data application that has three
windows. I wanted to control the appearance and disappearance of
these windows during the course of the application, so added menu
items and buttons with the action makeKeyAndOrderFront. However, I
found that the program hung while running: specifically while re-
opening a window that I had previously closed. The GDB message was
'Program received signal: “EXC_BAD_ACCESS”.' I couldn't get very
far with this: Tech Q&A 1367 said that it was probably the result of
over-releasing an object. I couldn't see how that had happened,
since I had really just gone with the code generated by Xcode: so I
wasn't knowlingly releasing anything that I could see. However,
after a bit more digging I realised that the problem was in IB: in
the Window attributes I noticed that the Behaviour option "Release
When Closed" was checked. When I unchecked this option the
application ran fine - no hang.
I suppose that when I close the window it is released, so when I try
to open it again there is nothing to open.
My questions are:
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.
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.
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)?
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?
Any illumination will be joyfully received.
Ian.
--
email@hidden
07590 685840 | 01926 811383
_______________________________________________
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
_______________________________________________
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