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.
Related
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.
My intent is to have 2 separate view controllers for a NSSplitView with two panes. In the left pane I want a table view, but it crashes. Here's the scenario:
I have a simple project with a MainMenu.xib, AppDelegate.h/m. In this project I add a LeftPaneViewController.h/.m/.xib.
In MainMenu.xib I add a NSSplitView to the default view.
In AppDelegate.h:
#property (weak) IBOutlet NSSplitView *splitView;
In AppDelegate.m:
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification
{
// Insert code here to initialize your application
LeftPaneViewController *lpvc = [[LeftPaneViewController alloc] initWithNibName:#"LeftPaneViewController" bundle:nil];
[self.splitView replaceSubview:[[self.splitView subviews] objectAtIndex:0] with:lpvc.view];
}
I connect the NSSplitView in MainMenu.xib to splitView in the AppDelegate.
When I run this works fine, but of course there is nothing to see yet.
In LeftPaneViewController.xib I add a NSTableView to the default custom view. I delete one of the columns (the bottom one in the list).
In LeftPaneViewController.h:
#interface LeftPaneViewController : NSViewController <NSTableViewDelegate, NSTableViewDataSource>
#property (weak) IBOutlet NSTableView *tableView;
#property (nonatomic, retain) NSMutableArray *tableDataSource;
In LeftPaneViewController.m:
#import "LeftPaneViewController.h"
#interface LeftPaneViewController ()
#end
#implementation LeftPaneViewController
- (id)initWithNibName:(NSString *)nibNameOrNil bundle:(NSBundle *)nibBundleOrNil
{
self = [super initWithNibName:nibNameOrNil bundle:nibBundleOrNil];
if (self) {
// Initialization code here.
}
return self;
}
- (void)awakeFromNib
{
self.tableDataSource = [[NSMutableArray alloc] initWithObjects:#"Row1", #"Row2", nil];
[self.tableView setNeedsDisplay];
}
- (NSInteger)numberOfRowsInTableView:(NSTableView *)tableView
{
// This is a defensive move
// There are cases where the nib containing the NSTableView can be loaded before the data is populated
// by ensuring the count value is 0 and checking to see if the namesArray is not nil, the app
// is protecting itself agains that situation
NSInteger count=0;
if (self.tableDataSource)
count=[self.tableDataSource count];
return count;
}
- (NSView *)tableView:(NSTableView *)tableView viewForTableColumn:(NSTableColumn *)tableColumn row:(NSInteger)row {
// Get an existing cell with the MyView identifier if it exists
NSTextField *result = [tableView makeViewWithIdentifier:#"LeftPaneCell" owner:self];
// There is no existing cell to reuse so create a new one
if (result == nil) {
// Create the new NSTextField with a frame of the {0,0} with the width of the table.
// Note that the height of the frame is not really relevant, because the row height will modify the height.
NSTextField *textField;
textField = [[NSTextField alloc] initWithFrame:NSMakeRect(2, 456, 125, 20)];
[textField setStringValue:#"My Label"];
[textField setBezeled:NO];
[textField setDrawsBackground:NO];
[textField setEditable:NO];
[textField setSelectable:NO];
[self.view addSubview:textField];
// The identifier of the NSTextField instance is set to MyView.
// This allows the cell to be reused.
result.identifier = #"LeftPaneCell";
}
// result is now guaranteed to be valid, either as a reused cell
// or as a new cell, so set the stringValue of the cell to the
// nameArray value at row
result.stringValue = [self.tableDataSource objectAtIndex:row];
// Return the result
return result;
}
#end
In the LeftPaneViewController.xib I hook the TableView dataSource and delegate to "File's Owner" (of LeftPaneViewController of course). and hook the tableView referencing outlet to the tableView in LeftPaneViewController.h. I checked these at least a thousand times ;-)
Then when I run I get the following crash log:
* thread #1: tid = 0x23427, 0x00007fff82893250 libobjc.A.dylib`objc_msgSend + 16, queue = 'com.apple.main-thread, stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
frame #0: 0x00007fff82893250 libobjc.A.dylib`objc_msgSend + 16
frame #1: 0x00007fff88f8d972 AppKit`-[NSTableRowData _addViewToRowView:atColumn:row:] + 324
frame #2: 0x00007fff88f8d63f AppKit`-[NSTableRowData _addViewsToRowView:atRow:] + 151
frame #3: 0x00007fff88f8bbd5 AppKit`-[NSTableRowData _addRowViewForVisibleRow:withPriorView:] + 415
frame #4: 0x00007fff88f8b95a AppKit`-[NSTableRowData _addRowViewForVisibleRow:withPriorRowIndex:inDictionary:withRowAnimation:] + 272
frame #5: 0x00007fff88f8ac29 AppKit`-[NSTableRowData _unsafeUpdateVisibleRowEntries] + 740
frame #6: 0x00007fff88f8a7c1 AppKit`-[NSTableRowData updateVisibleRowViews] + 119
frame #7: 0x00007fff88f625a7 AppKit`-[NSTableView layout] + 165
frame #8: 0x00007fff88f15e65 AppKit`-[NSView _layoutSubtreeHeedingRecursionGuard:] + 112
frame #9: 0x00007fff8d11b4a6 CoreFoundation`__NSArrayEnumerate + 582
frame #10: 0x00007fff88f15fc6 AppKit`-[NSView _layoutSubtreeHeedingRecursionGuard:] + 465
frame #11: 0x00007fff8d11b4a6 CoreFoundation`__NSArrayEnumerate + 582
frame #12: 0x00007fff88f15fc6 AppKit`-[NSView _layoutSubtreeHeedingRecursionGuard:] + 465
frame #13: 0x00007fff8d11b4a6 CoreFoundation`__NSArrayEnumerate + 582
frame #14: 0x00007fff88f15fc6 AppKit`-[NSView _layoutSubtreeHeedingRecursionGuard:] + 465
frame #15: 0x00007fff8d11b4a6 CoreFoundation`__NSArrayEnumerate + 582
frame #16: 0x00007fff88f15fc6 AppKit`-[NSView _layoutSubtreeHeedingRecursionGuard:] + 465
frame #17: 0x00007fff8d11b4a6 CoreFoundation`__NSArrayEnumerate + 582
frame #18: 0x00007fff88f15fc6 AppKit`-[NSView _layoutSubtreeHeedingRecursionGuard:] + 465
frame #19: 0x00007fff8d11b4a6 CoreFoundation`__NSArrayEnumerate + 582
frame #20: 0x00007fff88f15fc6 AppKit`-[NSView _layoutSubtreeHeedingRecursionGuard:] + 465
frame #21: 0x00007fff88f15cfe AppKit`-[NSView layoutSubtreeIfNeeded] + 615
frame #22: 0x00007fff88f114ac AppKit`-[NSWindow(NSConstraintBasedLayout) layoutIfNeeded] + 201
frame #23: 0x00007fff88e0b0a8 AppKit`_handleWindowNeedsDisplayOrLayoutOrUpdateConstraints + 446
frame #24: 0x00007fff893d6901 AppKit`__83-[NSWindow _postWindowNeedsDisplayOrLayoutOrUpdateConstraintsUnlessPostingDisabled]_block_invoke_01208 + 46
frame #25: 0x00007fff8d0e9417 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23
frame #26: 0x00007fff8d0e9381 CoreFoundation`__CFRunLoopDoObservers + 369
frame #27: 0x00007fff8d0c47b8 CoreFoundation`__CFRunLoopRun + 728
frame #28: 0x00007fff8d0c40e2 CoreFoundation`CFRunLoopRunSpecific + 290
frame #29: 0x00007fff8c17aeb4 HIToolbox`RunCurrentEventLoopInMode + 209
frame #30: 0x00007fff8c17ab94 HIToolbox`ReceiveNextEventCommon + 166
frame #31: 0x00007fff8c17aae3 HIToolbox`BlockUntilNextEventMatchingListInMode + 62
frame #32: 0x00007fff88e08533 AppKit`_DPSNextEvent + 685
frame #33: 0x00007fff88e07df2 AppKit`-[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 128
frame #34: 0x00007fff88dff1a3 AppKit`-[NSApplication run] + 517
frame #35: 0x00007fff88da3bd6 AppKit`NSApplicationMain + 869
frame #36: 0x0000000100001872 TableView_In_SplitView`main(argc=3, argv=0x00007fff5fbff7e8) + 34 at main.m:13
frame #37: 0x00007fff84d4d7e1 libdyld.dylib`start + 1
With breakpoints I determine that in LeftPaneViewController.m the numberOfRowsInTableView is called and returns 2, but viewForTableColumn is not called.
The TableView is Cell Based so I do expect the viewForTableColumn to be called.
If I simply add a NSTableView to the SplitView in MainMenu.xib and transfer the same code into AppDelegate.h/.m it works fine (and changing the hooks as well of course). That is, it does not crash and both numberOfRowsInTableView and viewForTableColumn are called.
So what am I not doing that is causing the crash?
Ok, found the answer. Since the LeftPaneViewController variable (lpvc) in AppDelegate.m was local it was being released after the replaceSubview call. So adding it as (nonatomic, retain) in AppDelegate.h fixed the crash. Turned on Zombies to find the answer ;-).
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.
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
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