Strange crash when presenting modal UIViewController - ios

I've seen this crash report a few times. It is extremely random and rare, and I can't understand it. All I am doing is presenting a modal view controller using the following code
ComposeController *newcontrol = [[ComposeController alloc]initWithMode:1 withNIB:#"ComposeController"];
newcontrol.delegate = self;
UINavigationController *holder = [[UINavigationController alloc] initWithRootViewController:newcontrol];
[self presentViewController:holder animated:YES completion:NULL];
Somehow this leads to this completely at random:
OS Version: iPhone OS 6.1 (10B143)
Report Version: 104
Exception Type: SIGSEGV
Exception Codes: SEGV_ACCERR at 0x9
Crashed Thread: 0
Thread 0 Crashed:
0 libobjc.A.dylib 0x3b25c5d0 objc_msgSend + 16
1 CoreFoundation 0x334ba73f -[__NSPlaceholderArray initWithObjects:count:] + 271
2 CoreFoundation 0x334bae09 +[NSArray arrayWithObject:] + 45
3 UIKit 0x353e80ab -[UIWindow _rotationViewControllers] + 51
4 UIKit 0x353e7fe3 -[UIViewController viewControllerForRotation] + 91
5 UIKit 0x353e7f39 -[UIViewController _visibleView] + 97
6 UIKit 0x3546c05b -[UIWindowController transition:fromViewController:toViewController:target:didEndSelector:] + 2483
7 UIKit 0x3546afab -[UIViewController presentViewController:withTransition:completion:] + 3399
8 MyApp 0x00046e97 -[Inbox composeHit] (Inbox.m:207)

I have the same problem quite consistently. It seems to be caused by the fact that I am presenting a modal view controller from a popover, which is not well tested and triggers a bug in Apple's code. The bug is that UIKit keeps an unretained reference to my View Controller which has been already dismissed and deallocated, so at a later time that reference is hit. My workaround is either to avoid presenting modal VCs from a popover, or to retain all such VCs myself indefinitely (in a member variable or some such).
Below are the gory details.
Here is the code I used to trigger the problem.
-(void) handlePinchFromCell:(AMPSupportingPhotoCell*) cell
{
UIViewController * vc = [[UIViewController alloc] init]; // UIViewController #0
[self presentViewController:vc animated:YES completion:nil];
[self performSelector:#selector(dismiss:) withObject:vc afterDelay:2];
}
-(void) dismiss:(UIViewController*)vc
{
[self dismissViewControllerAnimated:YES completion:^(){NSLog(#"-------");}];
}
This code is a part of a UIViewController #1, that is inside a UIPopoverController, that is popped over from another UIViewController #2, which is itself a presented from yet another view UIViewController #3. The crash happens after popover is closed, controller #2 id dismissed.
If I enable Zombies, I get the same stack trace but with a message:
2013-03-13 20:04:24.681 Mercury[16698:19d03] handlePinchFromCell: a225710
2013-03-13 20:04:27.083 Mercury[16698:19d03] -------
2013-03-13 20:04:31.606 Mercury[16698:19d03] *** -[UIViewController retain]: message sent to deallocated instance 0xa225710
So, notice that the VC #0 got allocated, presented, dismissed 2 seconds later, deallocated, and yet there is still a dangling reference to it somewhere in the Apple's code. When popover is closed and VC#2 is dismissed, the whole thing comes crashing down trying to access the deallocated VC. I am fairly certain this is Apple's bug. I also guess it's related to presenting a VC from a popover, so if you stay away from that, or retain the VC yourself you should be fine.
Another stack trace for the same problem is this. It happens if the above code is run twice:
2013-03-13 20:12:53.883 Mercury[16735:19d03] handlePinchFromCell: 16d54da0
2013-03-13 20:12:56.285 Mercury[16735:19d03] -------
2013-03-13 20:13:03.481 Mercury[16735:19d03] handlePinchFromCell: a2565f0
2013-03-13 20:13:03.481 Mercury[16735:19d03] *** -[UIViewController isKindOfClass:]: message sent to deallocated instance 0x16d54da0
(lldb) bt
* thread #1: tid = 0x1f03, 0x017f8a97 CoreFoundation`___forwarding___ + 295, stop reason = EXC_BREAKPOINT (code=EXC_I386_BPT, subcode=0x0)
frame #0: 0x017f8a97 CoreFoundation`___forwarding___ + 295
frame #1: 0x017f894e CoreFoundation`_CF_forwarding_prep_0 + 14
frame #2: 0x00c42f90 UIKit`-[UIWindowController transition:fromViewController:toViewController:target:didEndSelector:] + 907
frame #3: 0x00a40ee3 UIKit`-[UIViewController presentViewController:withTransition:completion:] + 4521
frame #4: 0x00a41167 UIKit`-[UIViewController presentViewController:animated:completion:] + 112
frame #5: 0x0006c32d Mercury`-[AMPSupportingPhotosViewController handlePinchFromCell:](self=0x16d55360, _cmd=0x0007a64a, cell=0x0a22a2a0) + 205 at AMPSupportingPhotosViewController.m:184
frame #6: 0x015336b0 libobjc.A.dylib`-[NSObject performSelector:withObject:] + 70
frame #7: 0x0006f317 Mercury`-[AMPSupportingPhotoCell handlePinch:](self=0x0a22a2a0, _cmd=0x00efb0db, sender=0x0a2504a0) + 215 at AMPSupportingPhotoCell.m:53
frame #8: 0x00c2185a UIKit`_UIGestureRecognizerSendActions + 139

Try doing this
[holder pushViewController:newcontrol animated:YES completion:NULL];

Related

how can I trace back beyond dispatch_async when debugging an iOS program?

I wonder if anyone knows how can I trace back beyond dispatch_async when debugging my iOS program. My program constant crash at two spots: in buffer_is_unused, as shown in and ,
and in release_shmem_bitmap, as shown in and . None of this happens at the main thread, and on the thread-local stack there is almost nothing except some dispatch_async and pthread jobs. Given my configuration of XCode, it gives me almost no information on who called this dispatched_async. I googled "release_shmem_bitmap" and found only a few webpage on the web and none of them are helpful. I wonder if anyone knows how can I make Xcode to show who called these dispatch_async or in general how shall I fix such crash?
iOS async stack trace record https://github.com/tiantianbobo/XBAsyncStackTrace
Suppose codes like this when compiled in release version:
- (void)callCrashFunc {
id object = (__bridge id)(void*)1;
[object class];
// NSLog(#"remove this line will cause tail call optimization");
}
- (void)testDispatchAsyncCrash {
dispatch_async(dispatch_get_global_queue(0, 0), ^{
[self callCrashFunc];
});
}
normal stack trace methods only get you this:
frame #0: 0x000000010186fd85 libobjc.A.dylib`objc_msgSend + 5
frame #1: 0x0000000104166595 libdispatch.dylib`_dispatch_call_block_and_release + 12
frame #2: 0x0000000104167602 libdispatch.dylib`_dispatch_client_callout + 8
frame #3: 0x000000010416a064 libdispatch.dylib`_dispatch_queue_override_invoke + 1028
frame #4: 0x000000010417800a libdispatch.dylib`_dispatch_root_queue_drain + 351
frame #5: 0x00000001041789af libdispatch.dylib`_dispatch_worker_thread2 + 130
frame #6: 0x0000000104553169 libsystem_pthread.dylib`_pthread_wqthread + 1387
frame #7: 0x0000000104552be9 libsystem_pthread.dylib`start_wqthread + 13
But you still don't know where actual code is.
However, XBAsyncStackTrace will give you:
0 XBAsyncStackTraceExample 0x000000010c89d75c blockRecordAsyncTrace + 76
1 XBAsyncStackTraceExample 0x000000010c89d302 wrap_dispatch_async + 98
2 XBAsyncStackTraceExample 0x000000010c89c02c -[ViewController testDispatchAsyncCrash] + 92
3 XBAsyncStackTraceExample 0x000000010c89be3d -[ViewController viewDidLoad] + 269
4 UIKitCore 0x0000000110ae44e1 -[UIViewController loadViewIfRequired] + 1186
5 UIKitCore 0x0000000110ae4940 -[UIViewController view] + 27
Bingo!

Unwinding through multiple views using a custom segue in iOS8 causes EXC_BAD_ACCESS

I have a storyboard-based app, for which I have created custom segues, which use a custom animation controller that I have created.
Everything works fine when segueing forward/unwinding back one screen at a time. However, when I try to unwind through a stack of screens (e.g. I had segued First->Second->Third and then try to unwind back Third->First), I get an EXC_BAD_ACCESS (code=1) error.
The Apple documentation for UIViewController.dismissViewControllerAnimated (https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIViewController_Class/index.html#//apple_ref/occ/instm/UIViewController/dismissViewControllerAnimated:completion:) says that
If you present several view controllers in succession, thus building a stack of presented view controllers, calling this method on a view controller lower in the stack dismisses its immediate child view controller and all view controllers above that child on the stack. When this happens, only the top-most view is dismissed in an animated fashion; any intermediate view controllers are simply removed from the stack. The top-most view is dismissed using its modal transition style, which may differ from the styles used by other view controllers lower in the stack.
So as I understand this, if I call ‘dismissViewControllerAnimated’ on First, it should dismiss Third using its modal transition style, and just remove Second from the stack.
Therefore my UnwindSegue.perform method is:
- (void)perform {
UIViewController *sourceViewController = self.sourceViewController;
UIViewController *destinationViewController = self.destinationViewController;
sourceViewController.modalPresentationStyle = UIModalPresentationFullScreen;
sourceViewController.transitioningDelegate = self;
[destinationViewController dismissViewControllerAnimated:YES completion:nil]; //Error occurs here
}
The last line crashes with the EXC_BAD_ACCESS error.
I’ve done some digging around (by enabling zombies), and it seems like UIViewController internally has a weak reference to my ‘forward’ segue -
FirstController.dismissViewControllerAnimated calls UIViewController._customAnimatorForDismissedController, which calls methods on the segue Second->Third (which no longer exists).
Anyone got any idea on whether this behaviour is expected, or where I'm going wrong? Everything works in iOS7.
ETA: Crash log
Incident Identifier: 821DC9AC-E1A1-4CCD-8A3F-718577C1634D
CrashReporter Key: 35442db1a2bdce63197d4abe696619ca29fe9675
Hardware Model: iPad4,1
Process: TestProject [3792]
Path: /private/var/mobile/Containers/Bundle/Application/B56179DF-3A3D-4C57-A5A0-910EF0BAEB8D/TestProject.app/TestProject
Identifier: com.xyz.TestProject
Version: 1 (1.0)
Code Type: ARM-64 (Native)
Parent Process: launchd [1]
Date/Time: 2015-02-10 17:32:35.524 +0000
Launch Time: 2015-02-10 17:32:15.301 +0000
OS Version: iOS 8.1.2 (12B440)
Report Version: 105
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x00000000554fbeb8
Triggered by Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libobjc.A.dylib 0x0000000197cd7bd0 objc_msgSend + 16
1 UIKit 0x000000018bb83c3c -[UIViewController _customAnimatorForDismissedController:] + 80
2 UIKit 0x000000018bb83a84 -[UIViewController _dismissViewControllerWithTransition:from:completion:] + 620
3 UIKit 0x000000018bb2c074 -[UIViewController dismissViewControllerWithTransition:completion:] + 948
4 UIKit 0x000000018bb2bc5c -[UIViewController dismissViewControllerAnimated:completion:] + 248
5 TestProject 0x00000001000cd768 -[XYZUnwindStoryboardSegue perform] (XYZUnwindStoryboardSegue.m:26)
6 UIKit 0x000000018ba90d30 -[UIApplication sendAction:to:from:forEvent:] + 92
7 UIKit 0x000000018ba79e44 -[UIControl _sendActionsForEvents:withEvent:] + 608
8 UIKit 0x000000018ba906cc -[UIControl touchesEnded:withEvent:] + 588
9 UIKit 0x000000018ba90358 -[UIWindow _sendTouchesForEvent:] + 696
10 UIKit 0x000000018ba898ac -[UIWindow sendEvent:] + 680
11 UIKit 0x000000018ba5cfa4 -[UIApplication sendEvent:] + 260
12 UIKit 0x000000018bcfbf54 _UIApplicationHandleEventFromQueueEvent + 14988
13 UIKit 0x000000018ba5b50c _UIApplicationHandleEventQueue + 1612
14 CoreFoundation 0x00000001872629e8 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 20
15 CoreFoundation 0x0000000187261c8c __CFRunLoopDoSources0 + 260
16 CoreFoundation 0x000000018725fd3c __CFRunLoopRun + 708
17 CoreFoundation 0x000000018718d0a0 CFRunLoopRunSpecific + 392
18 GraphicsServices 0x00000001902f35a0 GSEventRunModal + 164
19 UIKit 0x000000018bac23bc UIApplicationMain + 1484
20 TestProject 0x00000001000ce7ec main (main.m:14)
21 libdyld.dylib 0x0000000198332a04 start + 0
Thread 1 name: Dispatch queue: com.apple.libdispatch-manager
Thread 1:
0 libsystem_kernel.dylib 0x0000000198430c94 kevent64 + 8
1 libdispatch.dylib 0x0000000100141254 0x100130000 + 70228
2 libdispatch.dylib 0x0000000100132ef4 0x100130000 + 12020
Thread 2:
0 libsystem_kernel.dylib 0x000000019844bc78 __workq_kernreturn + 8
1 libsystem_pthread.dylib 0x00000001984e5390 _pthread_wqthread + 988
2 libsystem_pthread.dylib 0x00000001984e4fa4 start_wqthread + 0

Navigation controller crashes when pressing "back" while at the bottom of a tableView. If I scroll up slightly the program does not crash

I have two pages, each with a tableView in them. The first tableview leads to the second tableView when a cell is pressed via a push segue. I used "embed in" to apply a navigation controller to the first view controller which gives the second view a back button which works for 99% of the application. For some reason, if I scroll all the way down to the bottom of the second tableview and then press the back button, the application crashes with this error: Thread 1: EXC_BAD_ACCESS. The backtrace from the console is this:
(lldb) bt
* thread #1: tid = 0x9517c, 0x000000011115a00b libobjc.A.dylib`objc_msgSend + 11, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
frame #0: 0x000000011115a00b libobjc.A.dylib`objc_msgSend + 11
frame #1: 0x000000010ff1f462 UIKit`-[UIScrollView(UIScrollViewInternal) _notifyDidScroll] + 56
frame #2: 0x000000010ff0fa42 UIKit`-[UIScrollView setContentOffset:] + 645
frame #3: 0x000000010ff79b5f UIKit`-[UITableView setContentOffset:] + 362
frame #4: 0x000000010ff24360 UIKit`-[UIScrollView(UIScrollViewInternal) _adjustContentOffsetIfNecessary] + 1445
frame #5: 0x000000010ff214ef UIKit`-[UIScrollView(UIScrollViewInternal) _stopScrollingNotify:pin:tramplingDragFlags:] + 417
frame #6: 0x000000010ff102d6 UIKit`-[UIScrollView removeFromSuperview] + 32
frame #7: 0x000000010fee9e39 UIKit`-[UIView dealloc] + 404
frame #8: 0x00000001111588cd libobjc.A.dylib`(anonymous namespace)::AutoreleasePoolPage::pop(void*) + 591
frame #9: 0x000000010f045da6 CoreFoundation`_CFAutoreleasePoolPop + 22
frame #10: 0x000000010f079ef3 CoreFoundation`__CFRunLoopRun + 2051
frame #11: 0x000000010f079486 CoreFoundation`CFRunLoopRunSpecific + 470
frame #12: 0x0000000113e329f0 GraphicsServices`GSEventRunModal + 161
frame #13: 0x000000010fe8b420 UIKit`UIApplicationMain + 1282
* frame #14: 0x000000010eb9122e appname`top_level_code + 78 at AppDelegate.swift:13
frame #15: 0x000000010eb9126a appname`main + 42 at AppDelegate.swift:0
frame #16: 0x000000011191d145 libdyld.dylib`start + 1
(lldb)
If I scroll slightly up from the bottom of the second tableView, the program does not crash. The way I added the navigation controller was by clicking on the first view controller and using the "embed in" command. When the crash occurs, it takes me to the AppDelegate file as seen here:
What could be causing this program to crash in such a specific manner?
The error messages tells us that UIScrollView (which is part of the TableView) is trying to send a message to its delegate, that delegate appears to be deallocated at that point in time.
It seems like the UITableView is not being deallocated when you hit the back button, but the UIViewController is.
A very similar question has been asked here: UIScrollView EXC_BAD_ACCESS crash in iOS SDK
A first step to track down this problem would be implementing the dealloc method of your UIViewController subclass and setting the delegate of the UITableView to nil.
You should also turn on Zombies (Tracking down zombies with Xcode 5 on ios6) to get more information on which deallocated instance is receiving this message.

Very strange crash, may related to ARC and appears on iPhone 5s only

Thread : Crashed: com.apple.main-thread
0 libobjc.A.dylib 0x000000019a5639d0 objc_msgSend + 16
1 UIKit 0x00000001915af1d0 -[UISearchDisplayController _cleanUpSearchBar] + 196
2 UIKit 0x00000001915af0a0 -[UISearchBar willMoveToSuperview:] + 68
3 UIKit 0x0000000191788ea4 __UIViewWillBeRemovedFromSuperview + 192
4 UIKit 0x00000001914b83f4 -[UIView(Hierarchy) removeFromSuperview] + 72
5 UIKit 0x00000001914bb4fc -[UIView dealloc] + 424
6 UIKit 0x000000019159f354 -[UIScrollView dealloc] + 972
7 UIKit 0x000000019165fc40 -[UITableView dealloc] + 1304
8 UIKit 0x000000019159ed60 -[UIScrollView removeFromSuperview] + 80
9 UIKit 0x00000001914bb4fc -[UIView dealloc] + 424
10 UIKit 0x000000019165010c -[UIViewController dealloc] + 464
11 Gogobot 0x000000010017e560 -[GBListPageViewController dealloc] (GBListPageViewController.m:288)
12 Gogobot 0x0000000100189f84 __destroy_helper_block_982 (GBListPageViewController.m)
13 libsystem_blocks.dylib 0x000000019ab7f908 _Block_release + 256
14 libsystem_blocks.dylib 0x000000019ab7f908 _Block_release + 256
15 libsystem_blocks.dylib 0x000000019ab7f908 _Block_release + 256
16 Foundation 0x000000018f198b78 __destroy_helper_block_165 + 28
17 libsystem_blocks.dylib 0x000000019ab7f908 _Block_release + 256
18 Foundation 0x000000018f0a138c -[NSBlockOperation dealloc] + 68
19 libdispatch.dylib 0x000000019ab383e0 _dispatch_client_callout + 16
20 libdispatch.dylib 0x000000019ab3b56c _dispatch_main_queue_callback_4CF + 344
21 CoreFoundation 0x000000018e5aad64 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12
22 CoreFoundation 0x000000018e5a90a4 __CFRunLoopRun + 1452
23 CoreFoundation 0x000000018e4e9b38 CFRunLoopRunSpecific + 452
24 GraphicsServices 0x0000000193f0f830 GSEventRunModal + 168
25 UIKit 0x00000001915280e8 UIApplicationMain + 1156
26 Gogobot 0x0000000100202c20 main (main.m:16)
27 libdyld.dylib 0x000000019ab53aa0 start + 4
Here are the crash log i got from crashlytics. From this two lines, seems like something wrong with the dealloc,
11 Gogobot 0x000000010017e560 -[GBListPageViewController dealloc] (GBListPageViewController.m:288)
12 Gogobot
but i am using ARC, and didn't even implement anything in dealloc. It never happen to me when i test, but we got the same crash report from Crashlytcis, 10-20 times a day. And some user has 30% free ram. Doesn't look like memory issue. But all the report are coming from iPhone 5s.
I have been trying to reproduce that on my iphone 5s and 5. can't recreate at all... any idea would be appreciated.
here is my dealloc in my GBListPageViewController:
- (void)dealloc
{
[[NSNotificationCenter defaultCenter]removeObserver:self name:kGBListPageVCSortSelected object:nil];
[[NSNotificationCenter defaultCenter]removeObserver:self name:UIApplicationWillEnterForegroundNotification object:nil];
}
======================================================================
New Edit:
we try to remove delegate and observers in dealloc, but seems like that didn't solve the problem. And from our crash reports, seems like all the crashes happen on iphone5s + 7.0.x OS.
here is the code we used to remove delegate, pretty simply.
- (void)dealloc
{
[[NSNotificationCenter defaultCenter] removeObserver:self];
self.searchDisplayController.searchBar.delegate = nil;
self.searchDisplayController.delegate = nil;
}
Anyone has the same issue?...
My bet would be on the view controller being released before the view, while the view still has a reference to the delegate and tries to call a delegate method. I've seen many of these in iOS 7.X.
Set your search bar's and search display controller's delegates to nil in the view controller's dealloc.
I've had this problem as well. My workaround was rather unorthodox; in the segue's destination view controller, I set a property to hold a pointer to the source view controller, then set it to nil in viewWillAppear:animated. Like I said, it's unorthodox, but it works, giving the source view controller enough time to clean up before deallocating it.
Edit:
#property (nonatomic, strong) id vcToHoldForARCDeallocBug;
- (void)viewDidAppear:(BOOL)animated {
[super viewDidAppear:animated];
self.vcToHoldForARCDeallocBug = nil;
}
- (void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender {
self.vcToHoldForARCDeallocBug = segue.destinationViewController;
}
It sets a pointer to the destination view controller when it's presented. Once the user navigates back, in viewDidAppear it clears the pointer and allows ARC to deallocate the destination view controller since everything has been cleaned up by the time viewDidAppear is called.

MKMapView autorelease not calling dealloc after UIViewController is popped

I have the following code in class A:
UIViewController *vc = [self viewControllerForItem:item];
where the viewControllerForItem method in my app delegate returns a UIViewController based on my item i.e.
vc = [[[MyCustomViewController alloc] init] autorelease];
return vc;
I then push the view controller:
[self.navigationController pushViewController:vc animated:YES];
This VC i'm trying to push is a MKMapView and I inserted a log statement in the dealloc method to see if it's being called. In my memory usage, the growth is increasing pretty rapidly.
However, when I add the following code after pushing the VC:
[vc release];
my MKMapView class calls the dealloc method.
Of course this would be a simple solution if the MKMapView class was the only class returned by my app delegate (or I could just check if the VC's class is my MKMapView class). However, I would like to solve the root problem of this.
Why is the dealloc not being called if I set autorelease on my view controller?
How is it possible that I can add [vc release] to the view controller even though autorelease is used on that vc?
Thanks
Edit:
Here's some additional info. I have the viewControllerForItem class in my app delegate. I'm returning the auto released object into my other manager class where I then push the view controller. Is the retain count being messed up when I return an autoreleased object, and then push it in some other class?
This is the backtrace / callstack right when I push the VC and when the mkmapview's didDissappear is called:
pushVC: (
0 NewHampshire 0x00254cdf -[CustomViewController navigateToRowId:withLinkBehavior:animated:] + 2111
1 NewHampshire 0x002534c9 -[CustomViewController webView:shouldStartLoadWithRequest:navigationType:] + 841
2 UIKit 0x02caf288 -[UIWebView webView:decidePolicyForNavigationAction:request:frame:decisionListener:] + 318
3 UIKit 0x02cb1854 -[UIWebViewWebViewDelegate webView:decidePolicyForNavigationAction:request:frame:decisionListener:] + 77
4 CoreFoundation 0x05d0bd1d __invoking___ + 29
5 CoreFoundation 0x05d0bc2a -[NSInvocation invoke] + 362
6 CoreFoundation 0x05d0bdaa -[NSInvocation invokeWithTarget:] + 74
7 WebKit 0x0a4d811d -[_WebSafeForwarder forwardInvocation:] + 157
8 CoreFoundation 0x05d076da ___forwarding___ + 458
9 CoreFoundation 0x05d074ee _CF_forwarding_prep_0 + 14
10 CoreFoundation 0x05d0bd1d __invoking___ + 29
11 CoreFoundation 0x05d0bc2a -[NSInvocation invoke] + 362
12 WebCore 0x09533b29 _ZL20HandleDelegateSourcePv + 121
13 CoreFoundation 0x05ca083f __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 15
14 CoreFoundation 0x05ca01cb __CFRunLoopDoSources0 + 235
15 CoreFoundation 0x05cbd29e __CFRunLoopRun + 910
16 CoreFoundation 0x05cbcac3 CFRunLoopRunSpecific + 467
17 CoreFoundation 0x05cbc8db CFRunLoopRunInMode + 123
18 GraphicsServices 0x059749e2 GSEventRunModal + 192
19 GraphicsServices 0x05974809 GSEventRun + 104
20 UIKit 0x02a6ed3b UIApplicationMain + 1225
21 NewHampshire 0x000150dd main + 125
22 libdyld.dylib 0x04fab70d start + 1
)
disappear: (
0 NewHampshire 0x0014631d -[CustomAdvancedGPSMapViewController viewDidDisappear:] + 173
1 UIKit 0x02b85bac -[UIViewController _setViewAppearState:isAnimating:] + 341
2 UIKit 0x02b86328 -[UIViewController __viewDidDisappear:] + 150
3 UIKit 0x02b86461 -[UIViewController _endAppearanceTransition:] + 306
4 UIKit 0x02ba549a -[UINavigationController navigationTransitionView:didEndTransition:fromView:toView:] + 738
5 UIKit 0x02b9d403 __49-[UINavigationController _startCustomTransition:]_block_invoke + 206
6 UIKit 0x03176740 -[_UIViewControllerTransitionContext completeTransition:] + 99
7 UIKit 0x02a63454 __53-[_UINavigationParallaxTransition animateTransition:]_block_invoke105 + 680
8 UIKit 0x02ad1005 -[UIViewAnimationBlockDelegate _didEndBlockAnimation:finished:context:] + 306
9 UIKit 0x02abac6c -[UIViewAnimationState sendDelegateAnimationDidStop:finished:] + 267
10 UIKit 0x02abaf58 -[UIViewAnimationState animationDidStop:finished:] + 80
11 QuartzCore 0x028b2a44 _ZN2CA5Layer23run_animation_callbacksEPv + 304
12 libdispatch.dylib 0x04d194b0 _dispatch_client_callout + 14
13 libdispatch.dylib 0x04d0775e _dispatch_main_queue_callback_4CF + 340
14 CoreFoundation 0x05d7ca5e __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 14
15 CoreFoundation 0x05cbd6bb __CFRunLoopRun + 1963
16 CoreFoundation 0x05cbcac3 CFRunLoopRunSpecific + 467
17 CoreFoundation 0x05cbc8db CFRunLoopRunInMode + 123
18 GraphicsServices 0x059749e2 GSEventRunModal + 192
19 GraphicsServices 0x05974809 GSEventRun + 104
20 UIKit 0x02a6ed3b UIApplicationMain + 1225
21 NewHampshire 0x0001507d main + 125
22 libdyld.dylib 0x04fab70d start + 1
)
Solution: Although the responses in this post didn't provide the exact solution to my problem, Darren definitely steered me into the correct direction using the instruments tool. I found the culprit to be a CABasicAnimation object that was not being properly released.
in the viewWillDisappear method, I added the following for the CABasicAnimation object:
self.rotationAnimation.delegate = nil;
self.rotationAnimation = nil;
Use Instruments to track the retain/release history of CustomAdvancedGPSMapViewController and/or MKMapView :
In Xcode, select "Product > Profile" from the menu.
When Instruments starts, select the "Allocations" template.
If your app starts automatically, click the "Stop" button to stop it.
Click the "i" button on the Allocations instrument, and check "Record reference counts".
Select "View > Extended Detail" from the menu.
Click the "Record" button to start your app, and wait for your app to start in the simulator.
In the simulator, use your app to navigate to the CustomAdvancedGPSMapViewController.
In Instruments, click the "Pause" button
Use the search field in the top-right of the window and search for CustomAdvancedGPSMapViewController. CustomAdvancedGPSMapViewController should appear in the Allocation Summary list.
In the Allocation Summary list, Click the -> arrow next to the CustomAdvancedGPSMapViewController name. This should show that you have one instance of CustomAdvancedGPSMapViewController active in your app.
Click the -> arrow next to address. This will display the retain/release history for this CustomAdvancedGPSMapViewController instance.
Un-pause Instruments, return to the simulator, and dismiss your CustomAdvancedGPSMapViewController and return to the point where you believe the controller should be deallocated.
Return to Instruments, click "Pause" again, and look at the updated retain/release history.
The first event in the retain/release history should be "malloc". Select this row and the Extended Detail view in the right side of the window will display the stack trace for this allocation. You should see your own code in the stack trace. Double-click your code in the stack trace and you should see your line of code that allocated the the CustomAdvancedGPSMapViewController instance.
Above the code view, click the "History" tab to return to the history list.
The last event in the retain/release history should be "free". If that's not the case there may be a leak. Inspect the retain/release history and look for an unmatched retain. There may be a lot of noise, related to CoreAnimation, etc. Look for events in which your code appears in the stack trace.
Compare the retain/release history with a different view controller that is not leaking.
If CustomAdvancedGPSMapViewController isn't leaking, try inspecting the history of MKMapView.
The code which you have written is correct and you should not be releasing vc since it is been autoreleased already.
-(UIViewController *) viewControllerForItem: (Item*)item
{
/* create controller for the item --
* alloc init with increase the retain count of your object by 1
* autorelease will reduce the retain count of the object by 1
*/
return [[[MyCustomViewController alloc] init] autorelease];
}
UIViewController *vc = [self viewControllerForItem:item];
[self.NavigationController pushViewController:vc];
You cannot release 'vc' since you dont own it, in the sense you have not done 'alloc init' or 'retain' for it.
I have faced issues with Mapview's not releasing the memory even after getting released. It seems to be an apple bug and this memory will be destroyed only when you get a memory warning for mapview. But you can force the release by doing a hack.
Changing the mapType appears to release the memory the mapview is holding. So try resetting the mapType just before the release of the mapview object in mapviewcontroller. You can see the memory going down just after that statement is executed.
- (void)dealloc
{
// this is a trick for releasing memory
__mapView.mapType = MKMapTypeStandard;
[__mapView removeFromSuperview];
__mapView.delegate = nil;
[__mapview release];
[super dealloc];
}
Hope it helps.

Resources