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: Quincey Morris <email@hidden>
- Date: Fri, 4 Sep 2009 10:21:19 -0700
On Sep 4, 2009, at 09:35, Ian Piper wrote:
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.
Sometimes tracking down problems like this can be easy, sometimes
hard. Either way, you need a precise understanding of what you're
seeing, and based on the above description you don't have a lot of
precision.
When you get EXC_BAD_ACCESS, your app crashes, not hangs. Since you
were running monitored by gdb, the crash was intercepted by gbd, which
held the app in a stopped state. That's not what's usually meant by a
hang.
When gdb gets control, the first thing you need to do is to look at
the backtrace -- what was the app doing? In the easy cases, that will
tell you precisely what's going wrong (e.g. trying to message a
deallocated object). In the hard cases, it won't help much because you
crashed on a secondary error far beyond the point of the original
problem. Still, you should post the backtrace (or at least the first
few lines of it) to the list when asking for advice.
The problem isn't "in IB". It's in your code. Your code crashes when
"Release When Closed" is checked. Randomly flipping checkboxes in IB
until a crash apparently goes away is a pretty lousy approach to
application development. Knowing that your code crashes when "Release
When Closed" is checked is, however, a clue to what's wrong.
At the coding level, there's nothing that you can usefully call
"opening" a window, so the statement that "there is nothing to open"
makes no sense. Windows can be initialized, loaded, shown and ordered
front. Which of those gets done where and by whom depends on how the
window is defined.
If a window is released when it's closed, then you obviously have to
recreate (or cause to be recreated) a new NSWindow object if you want
to display the window again. If you're using a window controller
(which I highly recommend you do), then the window controller is
responsible for creating the NSWindow object (well, loading the
NSWindow object from the NIB, really). If you're trying to do without
a window controller, you're responsible for managing your window NIB
contents yourself, and that's a task with a few memory management
gotchas.
Most likely, your EXC_BAD_ACCESS is a memory management problem.
Either you're not managing the window NIB contents properly, or your
calls to makeKeyAndOrderFront: are using a pointer to a NSWindow that
got deallocated/garbage collected. Obviously, if "Release When Closed"
is checked, you can't just store a pointer to you windows somewhere
once at the start of application execution. You need to change those
pointers whenever a window is recreated. Or use a window controller to
do all this for you, since that's what it's for.
FWIW.
_______________________________________________
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