Re: [[object autorelease] release]
Re: [[object autorelease] release]
- Subject: Re: [[object autorelease] release]
- From: Rosyna <email@hidden>
- Date: Tue, 2 Oct 2001 05:56:56 -0700
I think the original question was why does it crash when you release
an autorelease object. I suggest, along with others that
NSAutoreleasePool check to see if an object in its pool has already
been released before it releases it. I see no problem with this, as
the functions to check if an object has been freed exists, and in
fact, you can make it ok to release an autorelease object if you set
NSAutoreleaseFreedObjectCheckEnabled to true as an environmental
variable, or call
[NSAutoreleasePool enableFreedObjectCheck:YES];
then it should not crash if you release an autoreleased object if I
am reading the headers correctly, but unfortunately it doesn't seem
to work.
Actually,
NSString* bob=@"Bob";
NSLog(bob);
[bob release];
doesn't crash unless I turn on the check. Hrmph, now I can't get it
to crash either way. Whatever.
Ack, at 10/2/01, Ondra Cada said:
Rosyna,
Rosyna (R) wrote at Tue, 2 Oct 2001 05:20:27 -0700:
R> In this case, there is no problem with that. And in the other case,
R> it'd check to see if that second object was freed as well. So I am
R> probably not understanding your objection to this.
I guess so. What's worse, I guess you don't understand the whole concept of
autorelease pools.
R> NSString* myString=[NSString stringWithString:@"Hi Mom!"]; // @"Hi
R> Mom!" puts weird data into the variable.
The variable myString contains a quite un-weird address of a newly made
NSString instance (which contains the quite un-weird string "Hi Mom!"). The
very same address is recorded in the current autorelease pool (*).
It used to put weird data into the string in some cases.
Namely:
NSString* bob=@"Bob";
bob=@"Not bob";
NSLog(bob);
Seems to no longer be the case.
R> [myString use];
Irrelevant (presumed no exception was raised and no
retain/release/autorelease was sent to myString)
R> [myString release];
The object at the address which is in myString gets its r.c. decremented; if
it happens to be a zero (which it does in our case), the object is
deallocated (the memory is freed, and can be used for a different object
(**)).
We *could* check all the autorelease pools here, and if the address
(myString) was in any of them, we could either ignore the release, or perform
the release and exclude the address from the pool. That would work quite
well, but it would be inefficient as hell.
If we *did not* check the pools, then, sooner or later -- perhaps later than
(**) above occured --, the pool marked (*) above will be released. As part
of the process, the object at the address recorded (see again (*)) would get
the release message.
Now you understand this:
--
Sincerely,
Rosyna Keller
Technical Support/Holy Knight/Always needs a hug
Unsanity: Unsane Tools for Insane People