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: Jonathan Hess <email@hidden>
- Date: Sun, 5 Oct 2008 18:47:54 -0700
On Oct 5, 2008, at 6:32 AM, Dr. Rolf Jansen wrote:
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?
An issue with manual reference counting (retain release in this case)
is that you have to pay attention to the possibility of reference
cycles. Most objects that act as the data source to a table view, have
a reference to the table view and retain it. If the table view also
retained the data source, then both objects would be retaining each
other. If both objects had a retain on the other, then neither of the
objects would ever be destroyed unless someone manually went in and
broke the cycle by removing the other's reference. To simplify these
problems, many references are non-retained. Data source is an example
of a reference which is typically non-retained. Delegate is also
typically non-retained, and so is a notification listener from
NSNotificationCenter.
Hope that helped -
Jon Hess
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
_______________________________________________
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