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: "Dr. Rolf Jansen" <email@hidden>
- Date: Sun, 5 Oct 2008 10:32:13 -0300
Am 05.10.2008 um 00:36 schrieb Michael Ash:
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.
...
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.
Because I need to overwrite the system implementation, in order to
prevent a crash.
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!
Of course this is a terrible workaround because generally you want
objects to go away eventually.
Of course!
- 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.)
OK, I understand this.
- 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!
Maybe.
Do not rely on it.
OK
- 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];
}
OK, thank you! That did indeed the trick.
Anyway, now I cannot understand, why the NSTableView does not retain
the dataSource, when it still needs it?
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.
OK, thank you. Sometimes it is helpful to get a refresh of the basics,
that became lost over the years.
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.
Yes, I did this, and it works :-) of course. Only, now it comes to my
mind that NSTableView should have done this with its datasource too,
and perhaps not the dealloc sequence has changed, but somehow some
NSTableView internals.
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.
This is clear to me now. Many thanks for your helpful response.
Rolf
_______________________________________________
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