UIScrollView setContentSize crashes with uncaught NSRangeException - objective-c

Call to setContentSize crashes the application after some of the UIScrollView's contents have been removed.
int toolbarHeight = [[[self navigationController] toolbar] frame].size.height;
int navbarHeight = [[[self navigationController] navigationBar] frame].size.height;
int totalHeight = toolbarHeight + navbarHeight;
// contentWidth is 640
CGSize contentSize = CGSizeMake(contentWidth, [scrollView frame].size.height - totalHeight);
[scrollView setContentSize:contentSize]; // Crash happens here, contentSize is perfectly valid
* Terminating app due to uncaught exception 'NSRangeException', reason: '* -[__NSArrayM objectAtIndex:]: index 1 beyond bounds [0 ..
0]'
What could be causing this?
EDIT: Here's the stack trace for those who can make any sense of it:
* thread #1: tid = 0x1c03, 0x34d2e32c libsystem_kernel.dylib`__pthread_kill + 8, stop reason = signal SIGABRT
frame #0: 0x34d2e32c libsystem_kernel.dylib`__pthread_kill + 8
frame #1: 0x36c2a20e libsystem_c.dylib`pthread_kill + 54
frame #2: 0x36c2329e libsystem_c.dylib`abort + 94
frame #3: 0x308eff6a libc++abi.dylib`abort_message + 46
frame #4: 0x308ed34c libc++abi.dylib`_ZL17default_terminatev + 24
frame #5: 0x36361356 libobjc.A.dylib`_objc_terminate + 146
frame #6: 0x308ed3c4 libc++abi.dylib`_ZL19safe_handler_callerPFvvE + 76
frame #7: 0x308ed450 libc++abi.dylib`std::terminate() + 20
frame #8: 0x308ee824 libc++abi.dylib`__cxa_rethrow + 88
frame #9: 0x363612a8 libobjc.A.dylib`objc_exception_rethrow + 12
frame #10: 0x34e9050c CoreFoundation`CFRunLoopRunSpecific + 404
frame #11: 0x34e9036c CoreFoundation`CFRunLoopRunInMode + 104
frame #12: 0x3618c438 GraphicsServices`GSEventRunModal + 136
frame #13: 0x31f86e7c UIKit`UIApplicationMain + 1080
frame #14: 0x0000cb50 App`main + 152 at main.m:16

It seems that the exception is thrown when the content offset is left outside the content size.
I had views side by side in the scroll view and the offset was to the last view.
+------+------+------+
| | |offset|
+------+------+------+
Now the last view is removed and the content size changed to a smaller one.
+------+------+
| | |offset
+------+------+
The offset is left behind.
I changed the code so that the offset is moved first, then the content size changed.
+------+------+
| |offset|
+------+------+
No crashes so far.

Related

Strange Cocoa crash on every ~10th run in the event loop

I'm building a simple Cocoa app from scratch, and right now I have a working app with one window.
The problem is it crashes on every ~10th run in [NSApp nextEventMatchingMask]. Here's the code:
#include <Cocoa/Cocoa.h>
void wait_for_events() {
NSEvent *event = [NSApp nextEventMatchingMask:NSEventMaskAny
untilDate:[NSDate distantFuture]
inMode:NSDefaultRunLoopMode
dequeue:YES];
[NSApp sendEvent:event];
}
int main() {
NSApplication sharedApplication];
[NSApp setActivationPolicy:NSApplicationActivationPolicyRegular];
[NSApp finishLaunching];
NSUInteger windowStyle =
NSTitledWindowMask | NSClosableWindowMask | NSMiniaturizableWindowMask;
NSWindow *window =
[[NSWindow alloc] initWithContentRect:NSMakeRect(0,0,300,300)
styleMask:windowStyle
backing:NSBackingStoreBuffered
defer:NO];
[window center];
[window retain];
[window orderFrontRegardless];
//[NSApp run];
while (1) {
wait_for_events();
}
}
I need access directly to the event loop, so I can't call [NSApp run]. I copied wait_for_events code from glfw.
I tried adding autorelease pool and disabling ARC via -fno-objc-arc
I tried this on 2 different machines with Sierra and High Sierra and still getting random EXC_BAD_ACCESS crashes:
Process 4925 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
frame #0: 0x00007fff50049290 libobjc.A.dylib`objc_destructInstance + 32
libobjc.A.dylib`objc_destructInstance:
-> 0x7fff50049290 <+32>: andq 0x20(%rax), %rcx
0x7fff50049294 <+36>: movb 0x2(%rcx), %cl
0x7fff50049297 <+39>: andb $0x2, %cl
0x7fff5004929a <+42>: shrb %cl
Target 0: (a.out) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
* frame #0: 0x00007fff50049290 libobjc.A.dylib`objc_destructInstance + 32
frame #1: 0x00007fff2973a201 CoreFoundation`_CFRelease + 1025
frame #2: 0x00007fff29600cf4 CoreFoundation`__CFBasicHashDrain + 388
frame #3: 0x00007fff29739f1c CoreFoundation`_CFRelease + 284
frame #4: 0x00007fff2967f68c CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 12
frame #5: 0x00007fff296620a3 CoreFoundation`__CFRunLoopDoBlocks + 275
frame #6: 0x00007fff2966172e CoreFoundation`__CFRunLoopRun + 1278
frame #7: 0x00007fff29660fa3 CoreFoundation`CFRunLoopRunSpecific + 483
frame #8: 0x00007fff28980866 HIToolbox`RunCurrentEventLoopInMode + 286
frame #9: 0x00007fff289804df HIToolbox`ReceiveNextEventCommon + 366
frame #10: 0x00007fff28980354 HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 64
frame #11: 0x00007fff26c7da23 AppKit`_DPSNextEvent + 2085
frame #12: 0x00007fff27412e6c AppKit`-[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 3044
frame #14: 0x0000000100011ef9 a.out`wait_for_events + 9
frame #15: 0x0000000100016030 a.out`main + 7
frame #16: 0x00000001000013f4 a.out`start + 52
I figured it out. There was another function with an uninitialized pointer.
I didn't even realize it was being called.
Somehow lldb didn't help me track it down.

iOS7 - UITabBarController seletedIndex crash

I am working on a TabBar based application. At some point I am doing:
if([[[appDelegate.tabBarController viewControllers] objectAtIndex:1] isKindOfClass:[UINavigationController class]]) {
UINavigationController *navController = [[appDelegate.tabBarController viewControllers] objectAtIndex:1];
[navController popToRootViewControllerAnimated:NO];
}
appDelegate.tabBarController.selectedIndex = 1; // CRASH HERE
On iOS6 it is working fine but when I build the application with XCode5 / iOS7 then the application crash here randomly. Please help me guys.
Thank you!
Crash Logs:
* thread #1: tid = 0x4b606, 0x0557f811 CoreFoundation`___forwarding___ + 769, queue = 'com.apple.main-thread, stop reason = EXC_BREAKPOINT (code=EXC_I386_BPT, subcode=0x0)
frame #0: 0x0557f811 CoreFoundation`___forwarding___ + 769
frame #1: 0x0557f4ee CoreFoundation`_CF_forwarding_prep_0 + 14
frame #2: 0x01128d6a UIKit`-[UISearchBar _didMoveFromWindow:toWindow:] + 168
frame #3: 0x00eca847 UIKit`-[UIView(Internal) _didMoveFromWindow:toWindow:] + 761
frame #4: 0x00eca847 UIKit`-[UIView(Internal) _didMoveFromWindow:toWindow:] + 761
frame #5: 0x00eca847 UIKit`-[UIView(Internal) _didMoveFromWindow:toWindow:] + 761
frame #6: 0x00ec2070 UIKit`__45-[UIView(Hierarchy) _postMovedFromSuperview:]_block_invoke + 162
frame #7: 0x00ec1ef8 UIKit`-[UIView(Hierarchy) _postMovedFromSuperview:] + 260
frame #8: 0x00ecd031 UIKit`-[UIView(Internal) _addSubview:positioned:relativeTo:] + 1847
frame #9: 0x00ec0521 UIKit`-[UIView(Hierarchy) addSubview:] + 56
frame #10: 0x00f5b1f8 UIKit`-[UITransitionView transition:fromView:toView:removeFromView:] + 1205
frame #11: 0x00f5ad3b UIKit`-[UITransitionView transition:fromView:toView:] + 62
frame #12: 0x00f5aadb UIKit`-[UITransitionView transition:toView:] + 123
frame #13: 0x00fafe45 UIKit`-[UITabBarController transitionFromViewController:toViewController:transition:shouldSetSelected:] + 1438
frame #14: 0x00faf262 UIKit`-[UITabBarController transitionFromViewController:toViewController:] + 63
frame #15: 0x00fab64b UIKit`-[UITabBarController _setSelectedViewController:] + 279
frame #16: 0x00fab470 UIKit`-[UITabBarController setSelectedIndex:] + 261
frame #17: 0x00014e6d TestApp`-[HomeViewController btn_TopRatedClicked:](self=0x0d813830, _cmd=0x0023559b, sender=0x0dbceb80) + 1533 at HomeViewController.m:707
frame #18: 0x02311874 libobjc.A.dylib`-[NSObject performSelector:withObject:withObject:] + 77
frame #19: 0x00e66c8c UIKit`-[UIApplication sendAction:to:from:forEvent:] + 108
frame #20: 0x00e66c18 UIKit`-[UIApplication sendAction:toTarget:fromSender:forEvent:] + 61
frame #21: 0x00f5e6d9 UIKit`-[UIControl sendAction:to:forEvent:] + 66
frame #22: 0x00f5ea9c UIKit`-[UIControl _sendActionsForEvents:withEvent:] + 577
frame #23: 0x00f5dd4b UIKit`-[UIControl touchesEnded:withEvent:] + 641
frame #24: 0x00ea40cd UIKit`-[UIWindow _sendTouchesForEvent:] + 852
frame #25: 0x00ea4d34 UIKit`-[UIWindow sendEvent:] + 1232
frame #26: 0x00e78a36 UIKit`-[UIApplication sendEvent:] + 242
frame #27: 0x00e62d9f UIKit`_UIApplicationHandleEventQueue + 11421
frame #28: 0x055188af CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 15
frame #29: 0x0551823b CoreFoundation`__CFRunLoopDoSources0 + 235
frame #30: 0x0553530e CoreFoundation`__CFRunLoopRun + 910
frame #31: 0x05534b33 CoreFoundation`CFRunLoopRunSpecific + 467
frame #32: 0x0553494b CoreFoundation`CFRunLoopRunInMode + 123
frame #33: 0x02b739d7 GraphicsServices`GSEventRunModal + 192
frame #34: 0x02b737fe GraphicsServices`GSEventRun + 104
frame #35: 0x00e6594b UIKit`UIApplicationMain + 1225
frame #36: 0x0000213d TestApp`main(argc=1, argv=0xbfffed08) + 141 at main.m:16
At HomeViewController.m:707 I have found following statement:
appDelegate.tabBarController.selectedIndex = 1; // CRASH HERE
You have solved the problem. The reason is that the view controller is released but the searchbar.delegate is not setting nil. So you can set searchBar.delegate = nil in dealloc of the view controller.
In iOS7, the navigation controller stack is crashed so I have done following:
NSMutableArray *allControllersArray = [[appDelegate.tabBarController viewControllers] mutableCopy];
SearchViewController *viewController2 = [[SearchViewController alloc] initWithNibName:#"SearchViewController" bundle:nil];
UINavigationController *search=[[UINavigationController alloc] initWithRootViewController:viewController2];
[allControllersArray replaceObjectAtIndex:1 withObject:search];
appDelegate.tabBarController.viewControllers = allControllersArray;
And after that:
appDelegate.tabBarController.selectedIndex = 1;

EXC_BAD_ACCESS after NSWindowWillCloseNotification removes window from Array

Say I have a menu button called 'Create window' that creates a new window:
MyWindowClass * window = [MyWindowClass new];
In order to retain it, I add it to a mutable array (declared and synthesised as _articleArray = [NSMutableArray new];)
[_articleArray addObject:window]
This works great. If I include:
NSLog(#"Windows in mem: %lu",_articleArray.count);
The number increments each time that I click the button and another window appears on the screen.
Now, if I attach a selector to this 'create window' function to identify when the window closes:
[[NSNotificationCenter defaultCenter] addObserver:self selector:#selector(windowClosed:) name:NSWindowWillCloseNotification object:window];
This creates an error:
-(void) windowClosed:(NSNotification*)notification {
[_articleArray removeObject:[notification object]];
NSLog(#"Windows in mem: %lu",_articleArray.count);
The NSLog decrements when I close a window as expected, but as soon as the function ends, it throws an EXC_BAD_ACCESS error (code 13, address=0,0)
0x7fff97878710: movq 24(%rax), %rax
I am very confused. The number decrements, so I can only think that the function is working. So what is happening here?
EDIT: (lldb) thread backtrace
* thread #1: tid = 0x1c07, 0x00007fff97878710 libobjc.A.dylib`objc_msgSend_vtable13 + 16, stop reason = EXC_BAD_ACCESS (code=13, address=0x0)
frame #0: 0x00007fff97878710 libobjc.A.dylib`objc_msgSend_vtable13 + 16
frame #1: 0x00007fff97571503 Foundation`__NSFireTimer + 80
frame #2: 0x00007fff993a6da4 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 20
frame #3: 0x00007fff993a68bd CoreFoundation`__CFRunLoopDoTimer + 557
frame #4: 0x00007fff9938c099 CoreFoundation`__CFRunLoopRun + 1513
frame #5: 0x00007fff9938b6b2 CoreFoundation`CFRunLoopRunSpecific + 290
frame #6: 0x00007fff8df260a4 HIToolbox`RunCurrentEventLoopInMode + 209
frame #7: 0x00007fff8df25e42 HIToolbox`ReceiveNextEventCommon + 356
frame #8: 0x00007fff8df25cd3 HIToolbox`BlockUntilNextEventMatchingListInMode + 62
frame #9: 0x00007fff92ce3613 AppKit`_DPSNextEvent + 685
frame #10: 0x00007fff92ce2ed2 AppKit`-[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 128
frame #11: 0x00007fff92cda283 AppKit`-[NSApplication run] + 517
frame #12: 0x00007fff92c7ecb6 AppKit`NSApplicationMain + 869
frame #13: 0x0000000100006942 myApp`main + 34 at main.m:13
frame #14: 0x00007fff9094f7e1 libdyld.dylib`start + 1
This answer has been moved from the comments in the question at the request of the OP
You need to ensure that you remove your NSWindowWillCloseNotification observer before the window is destroyed:
-(void) windowClosed:(NSNotification*)notification {
NSWindow *window = [notification object];
[[NotificationCenter defaultCenter] removeObserver:self
name:NSWindowWillCloseNotification
object:window];
[_articleArray removeObject:window];
NSLog(#"Windows in mem: %lu",_articleArray.count);
...
And also ensure that the window has its isReleasedWhenClosed property set to YES so that it cleans-up after itself when closed.

UIViewController purgeMemoryForReason: Crashing on iOS 5

So I've been seeing this crash pretty frequently in Crashlytics, both on iPad and iPad 2, running iOS 5. It looks like it's caused by a memory warning, but the stack trace doesn't reference any of my application code, just iOS frameworks:
0 libobjc.A.dylib objc_msgSend + 15
1 UIKit -[UIViewController purgeMemoryForReason:] + 64
2 Foundation __57-[NSNotificationCenter addObserver: selector: name: object:]_block_invoke_0 + 18
3 CoreFoundation ___CFXNotificationPost_block_invoke_0 + 70
4 CoreFoundation _CFXNotificationPost + 1406
5 Foundation -[NSNotificationCenter postNotificationName: object: userInfo:] + 66
6 Foundation -[NSNotificationCenter postNotificationName: object:] + 30
7 UIKit -[UIApplication _performMemoryWarning] + 80
8 UIKit -[UIApplication _receivedMemoryNotification] + 174
9 libdispatch.dylib _dispatch_source_invoke + 516
10 libdispatch.dylib _dispatch_queue_invoke + 50
11 libdispatch.dylib _dispatch_main_queue_callback_4CF + 156
12 CoreFoundation __CFRunLoopRun + 1268
13 CoreFoundation CFRunLoopRunSpecific + 300
14 CoreFoundation CFRunLoopRunInMode + 104
15 GraphicsServices GSEventRunModal + 156
16 UIKit UIApplicationMain + 1090
17 500px iOS main.m line 12
I've googled high and low but can't find any solutions to this. It looks like this is caused by over-releasing a UIViewController instance, but I'm using ARC, so I don't see how that could be the case.
I'm at a loss of how to even approach this. I can't even tell which UIViewController subclass is causing the issue. I've tried reproducing the problem in the simulator and on the device, but I can't find what causes it. Has anyone seen anything like this or have suggestions on how to approach reproducing the issue?
I think I've solved the issue. I was thinking about it, and the problem isn't the unloading of the UIViewController view, it's the posting of the actual low memory warning notification. There are several instances in my code where I call [[NSNotificationCenter defaultCenter] removeObserver:self]. This is fine in the dealloc method, but there were two instances of this in viewDidUnload methods.
I noticed this when my breakpoint in didReceiveMemory of one of the UIViewController's wasn't getting hit. The code in viewDidUnload was also unregistering self from other, system notifications as well, as detailed here.
I'm not going to mark this as an accepted answer until I verify that the crashes stop with the new update.
UPDATE: I've verified with Crashlytics that the problem has been fixed!
I noticed the exact same stack trace in crashes reported by HockeyApp for devices running on iOS 5.
I never called [[NSNotificationCenter defaultCenter] removeObserver:self] except inside dealloc, so this could not be the cause of the crash.
Here is how I was able reproduce the crash: from MasterViewController I push DetailViewController, then pop it by tapping the back button. Finally, I trigger a memory warning and the crash happens (on iOS 5 only).
It turns out that the DetailViewController instance is not released after being popped because of a retain cycle when using SVPullToRefresh:
#implementation DetailViewController
- (void) viewDidLoad
{
[super viewDidLoad];
[self.scrollView addPullToRefreshWithActionHandler:^{
[self refresh];
}];
}
#end
Since the DetailViewController is not released it’s still registered for memory warning notifications and this is what happens:
frame #0: 0x0004d61b MyApp`-[DetailViewController dealloc](self=0x089a5150, _cmd=0x024d2738) + 27 at DetailViewController.m:103
frame #1: 0x0227ae3d libobjc.A.dylib`_objc_rootRelease + 47
frame #2: 0x0227ae00 libobjc.A.dylib`objc_release + 48
frame #3: 0x0227c047 libobjc.A.dylib`objc_storeStrong + 39
frame #4: 0x0004e44c MyApp`__destroy_helper_block_ + 44 at DetailViewController.m:157
frame #5: 0x029b555d libsystem_sim_blocks.dylib`_Block_release + 166
frame #6: 0x0227ae00 libobjc.A.dylib`objc_release + 48
frame #7: 0x0227c047 libobjc.A.dylib`objc_storeStrong + 39
frame #8: 0x00084c8d MyApp`-[SVPullToRefreshView .cxx_destruct](self=0x08bf3af0, _cmd=0x00000001) + 525 at UIScrollView+SVPullToRefresh.m:121
frame #9: 0x0226630d libobjc.A.dylib`object_cxxDestructFromClass + 104
frame #10: 0x02270fde libobjc.A.dylib`objc_destructInstance + 38
frame #11: 0x02271015 libobjc.A.dylib`object_dispose + 20
frame #12: 0x0247a9a1 CoreFoundation`-[NSObject dealloc] + 97
frame #13: 0x00a8cdc7 UIKit`-[UIView dealloc] + 748
frame #14: 0x0227ae3d libobjc.A.dylib`_objc_rootRelease + 47
frame #15: 0x00a90b73 UIKit`-[UIView(Hierarchy) removeFromSuperview] + 194
frame #16: 0x00a8cc10 UIKit`-[UIView dealloc] + 309
frame #17: 0x00a9d6ff UIKit`-[UIScrollView dealloc] + 405
frame #18: 0x013ab36c Foundation`NSKVODeallocate + 105
frame #19: 0x0227ae3d libobjc.A.dylib`_objc_rootRelease + 47
frame #20: 0x00b21c12 UIKit`-[UIViewController setView:] + 447
frame #21: 0x00b21885 UIKit`-[UIViewController unloadViewForced:] + 117
frame #22: 0x00b2180b UIKit`-[UIViewController unloadViewIfReloadable] + 41
frame #23: 0x00b256ff UIKit`-[UIViewController purgeMemoryForReason:] + 75
frame #24: 0x00b2563b UIKit`-[UIViewController didReceiveMemoryWarning] + 41
frame #25: 0x00b2560d UIKit`-[UIViewController _didReceiveMemoryWarning:] + 33
frame #26: 0x0141ca29 Foundation`__57-[NSNotificationCenter addObserver:selector:name:object:]_block_invoke_0 + 40
frame #27: 0x02443855 CoreFoundation`___CFXNotificationPost_block_invoke_0 + 85
frame #28: 0x02443778 CoreFoundation`_CFXNotificationPost + 1976
frame #29: 0x0136119a Foundation`-[NSNotificationCenter postNotificationName:object:userInfo:] + 98
frame #30: 0x0136db03 Foundation`-[NSNotificationCenter postNotificationName:object:] + 55
frame #31: 0x00a64cf4 UIKit`-[UIApplication _performMemoryWarning] + 91
frame #32: 0x00a64e00 UIKit`-[UIApplication _receivedMemoryNotification] + 180
frame #33: 0x00a64f98 UIKit`__block_global_0 + 36
frame #34: 0x029f1450 libdispatch.dylib`_dispatch_source_invoke + 719
frame #35: 0x029edcc4 libdispatch.dylib`_dispatch_queue_invoke + 66
frame #36: 0x029ee4cf libdispatch.dylib`_dispatch_main_queue_callback_4CF + 295
frame #37: 0x023af803 CoreFoundation`__CFRunLoopRun + 2003
frame #38: 0x023aed84 CoreFoundation`CFRunLoopRunSpecific + 212
frame #39: 0x023aec9b CoreFoundation`CFRunLoopRunInMode + 123
frame #40: 0x038d07d8 GraphicsServices`GSEventRunModal + 190
frame #41: 0x038d088a GraphicsServices`GSEventRun + 103
frame #42: 0x00a5a626 UIKit`UIApplicationMain + 1163
frame #43: 0x00002b82 MyApp`main(argc=1, argv=0xbffff318) + 178 at main.m:15
Or in english: the SVPullToRefreshView instance is released as a result of the view being unloaded. Since the SVPullToRefreshView instance is the last object to hold a reference to the DetailViewController, it is released, then deallocated. But purgeMemoryForReason: was still doing things (i.e. accessing instance variables) with the just deallocated view controller, hence the crash.
Once diagnosed the solution was very simple: just avoid the retain cycle in the first place.
#implementation DetailViewController
- (void) viewDidLoad
{
[super viewDidLoad];
__typeof__(self) __weak weakSelf = self;
[self.scrollView addPullToRefreshWithActionHandler:^{
[weakSelf refresh];
}];
}
#end

Strange crash in iPad simulator (<= 4.3) only (EXC_BAD_ACCESS) - any idea?

Occasionally I am getting a really strange crash in the simulator only (<= 4.3). It happens when I press a button on a navigation controller embedded with in a popover. Under the popover there is an EAGLView which is rendering something. Memory is handled properly, etc... on device no problem at all.
Any idea?
Here is a call stack:
* thread #1: tid = 0x2c03, 0x00ab6707 CoreGraphics`CGColorGetAlpha + 17, stop reason = EXC_BAD_ACCESS (code=1, address=0x1cc9b72c)
frame #0: 0x00ab6707 CoreGraphics`CGColorGetAlpha + 17
frame #1: 0x00dc9871 QuartzCore`-[CALayer _renderBackgroundInContext:] + 97
frame #2: 0x00dc97af QuartzCore`-[CALayer renderInContext:] + 977
frame #3: 0x00dcf15c QuartzCore`-[CALayer _renderSublayersInContext:] + 444
frame #4: 0x00dc97e1 QuartzCore`-[CALayer renderInContext:] + 1027
frame #5: 0x00dcf15c QuartzCore`-[CALayer _renderSublayersInContext:] + 444
frame #6: 0x00dc97e1 QuartzCore`-[CALayer renderInContext:] + 1027
frame #7: 0x003434a9 UIKit`-[UIView(Internal) _renderSnapshotWithRect:inContext:] + 790
frame #8: 0x0067776d UIKit`-[UIClipCornerView _updateSnapshot] + 697
frame #9: 0x0067723c UIKit`-[UIRoundedCornerView didMoveToSuperview] + 51
frame #10: 0x0033c750 UIKit`-[UIView(Internal) _addSubview:positioned:relativeTo:] + 1080
frame #11: 0x0033aaa3 UIKit`-[UIView(Hierarchy) addSubview:] + 57
frame #12: 0x004df1ad UIKit`-[UILayoutContainerView _beginFastMode] + 259
frame #13: 0x003c0c74 UIKit`-[UIViewController(UINavigationControllerItem) setEditing:animated:] + 249
frame #14: 0x0051453b UIKit`-[UITableViewController setEditing:animated:] + 73
frame #15: 0x003b6d1e UIKit`-[UIViewController(UINavigationControllerItem) _toggleEditing:] + 77
frame #16: 0x0030b4fd UIKit`-[UIApplication sendAction:to:from:forEvent:] + 119
frame #17: 0x0051dcc3 UIKit`-[UIBarButtonItem(UIInternal) _sendAction:withEvent:] + 156
frame #18: 0x0030b4fd UIKit`-[UIApplication sendAction:to:from:forEvent:] + 119
frame #19: 0x0039b799 UIKit`-[UIControl sendAction:to:forEvent:] + 67
frame #20: 0x0039dc2b UIKit`-[UIControl(Internal) _sendActionsForEvents:withEvent:] + 527
frame #21: 0x0039c7d8 UIKit`-[UIControl touchesEnded:withEvent:] + 458
frame #22: 0x0032fded UIKit`-[UIWindow _sendTouchesForEvent:] + 567
frame #23: 0x00310c37 UIKit`-[UIApplication sendEvent:] + 447
frame #24: 0x00315f2e UIKit`_UIApplicationHandleEvent + 7576
frame #25: 0x018f0992 GraphicsServices`PurpleEventCallback + 1550
frame #26: 0x00f79944 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 52
frame #27: 0x00ed9cf7 CoreFoundation`__CFRunLoopDoSource1 + 215
frame #28: 0x00ed6f83 CoreFoundation`__CFRunLoopRun + 979
frame #29: 0x00ed6840 CoreFoundation`CFRunLoopRunSpecific + 208
frame #30: 0x00ed6761 CoreFoundation`CFRunLoopRunInMode + 97
frame #31: 0x018ef1c4 GraphicsServices`GSEventRunModal + 217
frame #32: 0x018ef289 GraphicsServices`GSEventRun + 115
frame #33: 0x00319c93 UIKit`UIApplicationMain + 1160
One more thing which seems to be important: when underlying EAGLView is hidden then it does not occur. GLView and Popover do not share any data - interesting, is not it? I suspect it comes when pressed button ("edit") wants to redraw/toggle to "blue" then some blending happens since popover heading is a kind of translucent. For me sounds like a simulator problem; anyone had anything like that?
Thanks for any answer,
wl
Set NSZombieEnabled, MallocStackLogging, and guard malloc in the debugger. Then, when your App crashes, type this in the gdb console:
(gdb) info malloc-history 0x543216
Replace 0x543216 with the address of the object that caused the crash (probably from this line: * thread #1: tid = 0x2c03, 0x00ab6707 CoreGraphics CGColorGetAlpha + 17, stop reason = EXC_BAD_ACCESS (code=1, address=0x1cc9b72c)) and you will get a much more useful stack trace and it should help you pinpoint the exact line in your code that is causing the problem.
See this article for more detailed instructions.
GDB gives me something like that:
Alloc: Block address: 0x12387ff0 length: 16
Stack - pthread: 0xa0014540 number of frames: 38
0: 0x5fb8e in GMmalloc_zone_malloc_internal
1: 0x5fd31 in GMmalloc_zone_malloc
2: 0x60327 in GMmalloc_zone_calloc
3: 0x60375 in GMcalloc
4: 0x132a2d4 in class_createInstance
5: 0xec65d8 in +[NSObject(NSObject) allocWithZone:]
6: 0x48218e in +[UIColor allocWithZone:]
7: 0xec63da in +[NSObject(NSObject) alloc]
8: 0x4812c6 in +[UIColor clearColor]
9: 0x15b1d in -[EAGLView initWithCoder:]
As we can see EAGLView is involved...
...and in fact after some digging I figured out the problem was to do with EAGLLayer background color. I declared it as follows:
eaglLayer.backgroundColor = (CGColorRef) [UIColor clearColor];
This generally worked fine until then.
I fixed it with:
CGColorSpaceRef rgb = CGColorSpaceCreateDeviceRGB();
const CGFloat clearColor[] = {0.0, 0.0, 0.0, 0.0};
eaglLayer.backgroundColor = CGColorCreate(rgb, clearColor);
CGColorSpaceRelease(rgb);
or shorter:
eaglLayer.backgroundColor = [UIColor clearColor].CGColor;
Since then no exception.
#chown: thanks for your tip.
wl