Q:

Random deallocation of UIViewController

I am having a heck of a time debugging an iOS app crash issue. I have a UIViewController where I define its UIView in loadView. I also retain a copy of the UIView so that I can send messages to it such as (the view has been rotated) things of that nature. In addition to this the UIView has its own delegate member (uses assign, does not retain the ref to parent) that contains an association to the parent. (This is a pattern used in one of the Apple docs - I'm wondering if this isn't part of my issue as there is a circular reference between the two objects)
Here is the hierarchical view of the objects:
UIViewController
+ UIView
  + NSNotificationCenter UIKeyboardDidShow
The issue occurs when the NSNotification for UIKeyboardDidShow fires and the parent delegate method gets called. I know that the delegate was set. However, somehow, somewhere the delegate is getting released. Also, the _bufferViewDelegate gets set only once. Lastly, this doesn't happen every time. It happens rarely. 
Here is the stack trace:
Exception Type:  EXC_CRASH (SIGABRT)
Exception Codes: 0x00000000, 0x00000000
Crashed Thread:  0

Last Exception Backtrace:
0   CoreFoundation                  0x325f288f __exceptionPreprocess + 163
1   libobjc.A.dylib                 0x34648259 objc_exception_throw + 33
2   CoreFoundation                  0x325f5a9b -[NSObject doesNotRecognizeSelector:] + 175
3   CoreFoundation                  0x325f4915 ___forwarding___ + 301
4   CoreFoundation                  0x3254f650 _CF_forwarding_prep_0 + 48
5   Buffer                          0x0008716d -[BufferView scrollToCursor] (BufferView.m:4348)
6   Buffer                          0x00080407 -[BufferView keyboardDidShow:] (BufferView.m:1379)
7   Foundation                      0x37f3d4ff __57-[NSNotificationCenter addObserver:selector:name:object:]_block_invoke_0 + 19
8   CoreFoundation                  0x325be547 ___CFXNotificationPost_block_invoke_0 + 71
9   CoreFoundation                  0x3254a097 _CFXNotificationPost + 1407
10  Foundation                      0x37eb13eb -[NSNotificationCenter postNotificationName:object:userInfo:] + 67
11  UIKit                           0x3209f029 -[UIInputViewTransition postNotificationsForTransitionEnd] + 789
12  UIKit                           0x3233a51f __53-[UIPeripheralHost(UIKitInternal) executeTransition:]_block_invoke_01008 + 159
13  UIKit                           0x320344db -[UIViewAnimationBlockDelegate _didEndBlockAnimation:finished:context:] + 215
14  UIKit                           0x3202eaab -[UIViewAnimationState sendDelegateAnimationDidStop:finished:] + 471
15  UIKit                           0x320343d5 -[UIViewAnimationState animationDidStop:finished:] + 53
16  QuartzCore                      0x342dbc2f CA::Layer::run_animation_callbacks(void*) + 203
17  libdispatch.dylib               0x35c4ae91 _dispatch_main_queue_callback_4CF$VARIANT$up + 197
18  CoreFoundation                  0x325c52ad __CFRunLoopRun + 1269
19  CoreFoundation                  0x325484a5 CFRunLoopRunSpecific + 301
20  CoreFoundation                  0x3254836d CFRunLoopRunInMode + 105
21  GraphicsServices                0x3169f439 GSEventRunModal + 137
22  UIKit                           0x32047cd5 UIApplicationMain + 1081
23  Buffer                          0x0005c20b main (main.m:20)
24  Buffer                          0x0005bcac start + 40

UPDATE 2:
Resolved the issue. What I did was put NSLog statements in both the controller and all subviews to determine if everything was getting released as I expected. It wasn't. What I expected, and occurred most of the time, was this:
UIViewController loadView <-- Open the view, init the BufferView
UIViewController dealloc
BufferView dealloc

What was happening was that sometimes the BufferView never had its dealloc method called!
The code in the UIViewController looked something like this:
- (void)loadView
{
    ...

    // bufferView is a member var of this particular UIViewController
    bufferView = [[BufferView alloc] init];
    [self addSubview:view];

    ...
}

When the UIViewController dealloc method was called I would release the bufferView.
- (void)dealloc
{
    ...

    [bufferView release];
    bufferView = nil;

    ...

    [super dealloc];
}

When I changed the code to this in the loadView:
- (void)loadView
{
    ...

    // bufferView is a member var of this particular UIViewController
    bufferView = [[BufferView alloc] init];
    [self addSubview:view];
    [bufferView release];

    ...
}

and removed the release command in dealloc everything started working as I expected. It seems like best practice is to release the view after adding it to the subview. I've seen this pattern in other applications but never understood why it had to be this way. Hope this helps someone else out.
Please note that I haven't experienced a crash in over a day. This is way better than it was before. I'll update the ticket if this turns out to be the wrong solution.
UPDATE 3
The above did not work. I am now registering/unregistering the notifications in the UIViewController viewWillAppear, viewDidDisappear methods. Problem solved. So far as I can tell everyone's suggestion is to put the [[NSNotification defaultCenter] removeObserver:self] call in dealloc. This is not a good idea at all. You can not rely on the system to dealloc your object in the time frame you are expecting it to occur. Maybe in some cases it will work just fine, but not in all. I suggest that you try to register/unregister the calls only when you need them. In my case I only need them when the view is being displayed and unregistering when the view is not being displayed. Crash free for a day (we'll see how long that lasts). I'll update in a few days with my success.
UPDATE 4
That was the issue. No more crashes. So make sure you are registering your observers only when you absolutely need them and unregister them when you don't.

A:

To find out when an object is dealloced, placed an NSLog in it's dealloc routine.  And placing an address stop in the dealloc will allow you to display the call stack and see who is doing the release that frees the object.
I suspect what you have is that the object is actually getting dealloced even sooner than you think, but during the timer event the storage is recycled, and that's when the error is detected.

