Re: premature dealloc of the datasource of a NSTableView crashes my application
Re: premature dealloc of the datasource of a NSTableView crashes my application
- Subject: Re: premature dealloc of the datasource of a NSTableView crashes my application
- From: "Michael Ash" <email@hidden>
- Date: Sat, 4 Oct 2008 23:36:44 -0400
On Sat, Oct 4, 2008 at 4:01 PM, Dr. Rolf Jansen <email@hidden> wrote:
> Mac OS X 10.5.5, Xcode 3.1.1, PowerBook G4.
>
> I have developed a Document Based Cocoa application, and the main document
> window contains a simple datasource based NSTableView. After I recently
> re-built everything with Xcode 3.1.1, my application crashes when I close
> any document window. Everything document, datasource, tableview are
> instantiated in the NIB file that is owned by the document object.
>
> It took me some time to find out what is going on, anyway I am quite sure
> that the reason for the crash is a premature dealloc of the datasource of
> the NSTableView, in the course of closing the document window. In order to
> prevent my application from crashing, I overwrote -[NSObject dealloc] of the
> datasource to the following:
>
> - (void)dealloc
> {
> return;
> [super dealloc]; // this prevents the warning that
> } // [super dealloc] is not called.
>
>
> Unbelievable, but true - I checked this several times, that this prevents my
> application from crashing.
Not sure why you think this is unbelievable. Unlike in some other
languages, memory allocation and deallocation in Objective-C are
regular messages just like any other. Here, you are intercepting the
-dealloc method and preventing it from getting to the NSObject
implementation of it, which is where it actually destroys your object.
So your object never gets destroyed, and your app never crashes. Of
course this is a terrible workaround because generally you want
objects to go away eventually.
> - what determines the order of dealloc of
> NIB instances once a document closes?
A lot of complicated things that you shouldn't rely on. (Basically it
will depend on exactly what's retaining everything and in what order
things get released, which in turn can depend on things like hash
table ordering.)
> - is it possible that this order changed
> somehow between Xcode 3.1.1 and Xcode 3.1
It's possible that this order changed somehow between one run of your
app and the next! Do not rely on it.
> - can I set the dealloc sequence somehow myself,
> e.g. by dragging the objects of the NIB
> into a certain order?
Absolutely not. Write your code to work with any order. In this case,
what you should do is write your data source to nil out the table's
reference to it when it goes away:
- (void)dealloc {
[tableView setDataSource:nil];
[super dealloc];
}
> Probably not exactly related to this, I experience another issue of
> premature dealloc, that also occurred only recently, without changing any
> code of my application.
>
> The document has one independent main document window and it can open many
> dependent windows. When closing the main window, then the document and with
> that the dependent windows are forced to close too
> (-[MainDocWindowController setShouldCloseDocument:YES]). All of a sudden, my
> application deallocs the document object and its instances first, and then
> the dependent window objects. Also because of this my application started to
> crash, because for cleaning up, the dependent window objects are still
> needing to access some resources of the document object, that unfortunately
> has been dealloced prematurely.
If they need to access these resources then they should retain them.
If you need an object to stay alive, *make* it stay alive. Don't
assume that other bits of the system will do this for you.
> Any ideas, on how I can enforce the previous more logical dealloc sequence -
> the dependent window objects first, then the main window object, and finally
> the document object itself?
You can't.
Mike
_______________________________________________
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