Why wouldn't breaking-retain-cycle fall into infinite-loop like this? - ios

Question

Below is my code to verify the question.
0. Mock a retain-cycle
I create two classes, A & B:
#interface A : NSObject
#property (strong, nonatomic) B *b;
#end
#implementation A
- (void)dealloc
{
[_b release];
[super dealloc];
}
#end
//
#interface B : NSObject
#property (nonatomic, strong) A *a;
#end
#implementation B
- (void)dealloc
{
[_a release];
[super dealloc];
}
#end
// And in StrongViewController, there are tempA and tempB, which are both assign proprety:
#interface StrongViewController ()
#property (nonatomic, assign) A *tempA;
#property (nonatomic, assign) B *tempB;
#end
// In viewDidLoad, I create the retain-cycle, a & b retain each other:
A *a = [[[A alloc] init] autorelease];
B *b = [[[B alloc] init] autorelease];
a.b = b;
b.a = a;
self.tempA = a;
self.tempB = b;
// Then in viewWillDisappear, I try to break the retain-cycle:
[super viewWillDisappear:animated];
self.tempA.b = nil; // Key line
// Now, dive into the cycle step by step.
1. Using default setter to break retain-cycle
I set two breakpoints in A's dealloc & B's dealloc:
// Now when the key line self.tempA.b = nil; was executed:
// B's dealloc was called because release message was sent to b in A's setB:
// In B's dealloc, release message was sent to a, so A's dealloc was called then:
// Now, _b is nil because we use the default setB:, so it's okay to go through.
2. Using custom setter to break retain-cycle
// But what if using a custom setB: like below:
// When the key line self.tempA.b = nil; was executed, it runs into the custom setB::
// Now release was sent to b, so it goes to B's dealloc:
// Notice that in B's dealloc, [self retainCount] is still 1, not 0, why?
// Here in B's dealloc, release was sent to _a, so it will go to A's dealloc in turn, and in there release will be sent to _b:
// Here comes the difference, in A's dealloc, _b is not nil, and _b's retainCount is 1.
// According to my knowledge, if _b receives a release message now, it will call its dealloc then, because its retainCount is 1 for the moment.
// But, out of my imagination, it doesn't step into B's dealloc recursively, but just step over to the next line, leaving the retainCount with a big value 2147483648:
3. My question
// My question is on the above, why it step over when _b receives a release message, instead of stepping into its dealloc, while its retainCount is still 1 ?
// And how the retainCount 2147483648 comes out?
// To the depth, how the NSObject works when it receives a 'release' message indeed, anyone knows the source code? Even in A's dealloc, a's retainCount` is still 1, so is b.

Answer 1

When you release an object with a retain count of 1, the following happens:
The object is marked as "dead".
The dealloc method is called.
The memory of the object is returned to the OS.
retain and release have no effect when the object is marked as dead. The runtime doesn't even bother setting the retain count to zero before calling dealloc. When your second dealloc method gets called and tries to release an object that is already dead, even though retainCount returns 1, nothing happens. dealloc is never called twice for the same object.

Answer 2

http://www.opensource.apple.com/source/objc4/objc4-532/runtime/NSObject.mm is worth checking out.
I think the problem has to do with hasCustomRR() but I find the code tricky to follow so could be wrong.

Answer 3

It is not to keep cyclic references between objects !!!
But it is required some time to use such references to get our task done.
So I will suggest if you have one of the object is dependent on other then you can make on of the reference WEAK.It will assure breaking cyclic looping of references. you can refer http://www.cocoawithlove.com/2009/07/rules-to-avoid-retain-cycles.html tutorial for more explanation.