I am using testflight to test my app, and I have a crash that only occurs when the app is built for ad-hoc and distributed through test flight. The relevant crash report details are:
Date/Time: 2012-06-11 09:00:34.638 +0800
OS Version: iPhone OS 5.1.1 (9B206)
Report Version: 104
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00000009
Crashed Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libobjc.A.dylib 0x34e74f78 objc_msgSend + 16
1 appName 0x0002963e __24-[XYPieChart reloadData]_block_invoke_0168 (XYPieChart.m:321)
2 libdispatch.dylib 0x30295c52 _dispatch_call_block_and_release + 6
3 libdispatch.dylib 0x302a0e8a _dispatch_main_queue_callback_4CF$VARIANT$up + 190
4 CoreFoundation 0x371482a6 __CFRunLoopRun + 1262
5 CoreFoundation 0x370cb49e CFRunLoopRunSpecific + 294
6 CoreFoundation 0x370cb366 CFRunLoopRunInMode + 98
7 GraphicsServices 0x3388a432 GSEventRunModal + 130
8 UIKit 0x30e77cce UIApplicationMain + 1074
9 appName 0x00003b20 main (main.m:14)
10 appName 0x00003ad8 0x1000 + 10968
and the code that is referenced - (XYPieChart.m:321)
[CATransaction begin];
[CATransaction setAnimationDuration:_animationSpeed];
[_pieView setUserInteractionEnabled:NO];
__block NSMutableArray *layersToRemove = nil;
[CATransaction setCompletionBlock:^{
if (layersToRemove) {
[layersToRemove enumerateObjectsUsingBlock:^(id obj, NSUInteger idx, BOOL *stop) {
if (obj)
[obj removeFromSuperlayer];
}];
[layersToRemove removeAllObjects];
}
for(SliceLayer *layer in _pieView.layer.sublayers)
{
[layer setZPosition:kDefaultSliceZOrder];
}
[_pieView setUserInteractionEnabled:YES];
}];
BOOL isOnStart = ([slicelayers count] == 0 && sliceCount);
NSInteger diff = sliceCount - [slicelayers count];
layersToRemove = [NSMutableArray arrayWithArray:slicelayers];
BOOL isOnEnd = ([slicelayers count] && (sliceCount == 0 || sum <= 0));
if(isOnEnd)
{
for(SliceLayer *layer in _pieView.layer.sublayers){
[self updateLabelForLayer:layer value:0];
[layer createArcAnimationForKey:#"startAngle"
fromValue:[NSNumber numberWithDouble:_startPieAngle]
toValue:[NSNumber numberWithDouble:_startPieAngle]
Delegate:self];
[layer createArcAnimationForKey:#"endAngle"
fromValue:[NSNumber numberWithDouble:_startPieAngle]
toValue:[NSNumber numberWithDouble:_startPieAngle]
Delegate:self];
}
[CATransaction commit];
return;
}
I would be able to track down the problem if I could reproduce it when debugging but it only seems to occur when built for ad-hoc. Thanks!
Edit:
Using the simulator, I have tracked down the problem to a EXC_BAD_ACCESS at this line
[layersToRemove enumerateObjectsUsingBlock:^(id obj, NSUInteger idx, BOOL *stop) {
I had a similar problem and tried changing the project build settings, but it didn't work for me. Eventually solved my problem by changing the compiler optimization level setting for the release:
In Build Settings, go to the LLVM compiler 4.2 - Code Generation section, look for the Optimization Level option and change the Release setting from Fastest, Smallest [-Os] to None [-O0].
Hope this helps!
Change your Xcode Scheme so that you can Test and Debug a Release build, which uses the same compiler optimizations as your Ad Hoc build. Debugging a Debug build does not.
I ended up working out the problem. In my compiler settings, somehow, ARC wasn't enabled for Ad-Hoc builds resulting in weird behaviour. Before I worked this out, allocating the __block variable worked because in non-ARC environments, __block variables are not retained automatically.
Changed compiler settings so that all builds use ARC and everything was fixed.
In my case it was the "Enable Zombie Objects" setting that prevented the crash in debug mode. Debuggin without this setting made the app also crash in the debugger making it easy to find the culprit.
So I would advice to disable all settings in the "diagnostics" menu and set the optimizations to -Os and make a final test before releasing. Or as hotpaw2 pointed out, build in release mode. But this did not work for me due to issues with the certificate settings.
Related
After updating to 10.10.3 the WebView component started to crash after dealloc
- (void)dealloc {
[self.webView.windowScriptObject setValue:nil forKey:#"CocoaApp"];
[[self.webView mainFrame] stopLoading];
[self.webView setUIDelegate:nil];
[self.webView setEditingDelegate:nil];
[self.webView setFrameLoadDelegate:nil];
[self.webView setPolicyDelegate:nil];
[self.webView removeFromSuperview];
}
The crash happens somewhere deep in WebView
EXC_BAD_ACCESS
1 0x7fff910bae9e WebDocumentLoaderMac::detachFromFrame()
2 0x7fff920288c0 WebCore::FrameLoader::detachFromParent()
3 0x7fff910d0e55 -[WebView(WebPrivate) _close]
4 0x7fff910d0c49 -[WebView dealloc]
5 0x7fff8b1cf89c objc_object::sidetable_release(bool)
6 0x7fff8b1b5e8f (anonymous namespace)::AutoreleasePoolPage::pop(void*)
7 0x7fff912b26f2 _CFAutoreleasePoolPop
8 0x7fff8830e762 -[NSAutoreleasePool drain]
9 0x7fff8e3f0cc1 -[NSApplication run]
10 0x7fff8e36d354 NSApplicationMain
11 0x1000ebb12 main
12 0x7fff8c81e5c9 start
13 0x3
Any ideas? Is this a Apple bug? It started AFTER 10.10.3?
It doesn't crash when NSZombie is enabled!
I noticed you're using your own policy delegate:
[self.webView setPolicyDelegate:nil];
There's a known bug related to policy delegates in WebKit (only very recently fixed):
https://bugs.webkit.org/show_bug.cgi?id=144975
The short version is that you're probably hitting this assertion (which crashes the process with an intentional segfault):
https://github.com/WebKit/webkit/blob/24b1ae89efc10a4e6a6057b429c8e1d8d138a32f/Source/WebCore/loader/DocumentLoader.cpp#L935
because your policy handler (i.e. decidePolicyForMIMEType:request:frame:decisionListener:) is failing to make a policy decision (i.e not use, ignore, or download). The decision hangs around unmade, and when the loader eventually detaches it asserts that there are no pending policy decisions, which fails since the view is still waiting for a decision.
The fix i made, is not to release the webview, but hold a static reference into it (this is far from solving it and i contacted Apple regarding this issue)
#warning HOTFIX
{
//this is because of http://stackoverflow.com/questions/29746074/osx-10-10-3-crashes-webview-on-dealloc
static NSMutableArray * LIVE_FOR_EVER_WEBVIEW;
if (LIVE_FOR_EVER_WEBVIEW == nil) {
LIVE_FOR_EVER_WEBVIEW = [NSMutableArray new];
}
if (self.webView) {
[LIVE_FOR_EVER_WEBVIEW addObject:self.webView];
}
}
I have implemented a concurrent nsoperation and have ARC enabled. Now my customer is experiencing a crash which I cannot reproduce. He sent me the follow crash log :
Date/Time: 2013-04-24 12:23:34.925 -0400
OS Version: Mac OS X 10.8.3 (12D78)
Report Version: 10
Interval Since Last Report: 30946 sec
Crashes Since Last Report: 1
Per-App Interval Since Last Report: 33196 sec
Per-App Crashes Since Last Report: 1
Anonymous UUID: FB8460EE-5199-C6FB-55DC-F927D7F81A80
Crashed Thread: 15 Dispatch queue: com.apple.root.default-priority
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: EXC_I386_GPFLT
Application Specific Information:
objc_msgSend() selector name: isCancelled
Thread 15 Crashed:: Dispatch queue: com.apple.root.default-priority
0 libobjc.A.dylib 0x00007fff877f1250 objc_msgSend + 16
1 Myapp 0x000000010a608807 0x10a601000 + 30727
2 Myapp 0x000000010a650575 0x10a601000 + 324981
3 com.apple.Foundation 0x00007fff8b66212f -[NSBlockOperation main] + 124
4 com.apple.Foundation 0x00007fff8b638036 -[__NSOperationInternal start] + 684
5 com.apple.Foundation 0x00007fff8b63f861 __block_global_6 + 129
6 libdispatch.dylib 0x00007fff832d0f01 _dispatch_call_block_and_release + 15
7 libdispatch.dylib 0x00007fff832cd0b6 _dispatch_client_callout + 8
8 libdispatch.dylib 0x00007fff832ce1fa _dispatch_worker_thread2 + 304
9 libsystem_c.dylib 0x00007fff87d19d0b _pthread_wqthread + 404
10 libsystem_c.dylib 0x00007fff87d041d1 start_wqthread + 13
My code looks like this:
-(void)start
{
// Always check for cancellation before launching the task.
if ([self isCancelled])
{
// Must move the operation to the finished state if it is canceled.
[self onCancelSyncOperation];
return;
}
// If the operation is not canceled, begin executing the task.
[self willChangeValueForKey:#"isExecuting"];
[NSThread detachNewThreadSelector:#selector(main) toTarget:self withObject:nil];
executing = YES;
[self didChangeValueForKey:#"isExecuting"];
}
- (void)onCancelSyncOperation
{
[self willChangeValueForKey:#"isFinished"];
[self willChangeValueForKey:#"isExecuting"];
executing = NO;
finished = YES;
[self didChangeValueForKey:#"isExecuting"];
[self didChangeValueForKey:#"isFinished"];
}
It seems like the nsoperation is already released? when it tries to check for isCancelled?
Is this possible?
I don't think anyone can tell you why your app crashes by looking at this log. I haven't looked at your code, but you cut your crash-log, so it only shows system modules (lib.dispatch..., com.apple...). Typically the error is in the first occurrence of "com.myname...".
If this kind of crash EXC_BAD_ACCESS (SIGSEGV) appears along with an objc_msgSend(), it probably means you're trying to message to an object (or in other words: call a method of an object) that isn't there anymore. If you call that object, chances are very good that you'll find it, if you call it delayed or on another Thread or from a block, it will be a bit more complicated.
Your best chance to find the cause of this is to inspect your app with Instrument, using the Allocations or Leaks tool with NSZombies enabled (which is the default). You can launch Instruments from within Xcode. Then try to reproduce your crash. If you succeed, you might be able to find the class and location where the crash occurs.
If you don't know what to do with this answer, then check out the WWDC Developer Videos from Apple, there are some that show how to profile your app with Instruments (you'll need a [free] Dev Account to access the videos).
Good luck!
I have an app for Mac and iOS that uses .plist files to sync data between devices using iCloud. Every once in a while I get an email from someone that's getting repeated crashes on a specific device. (Other devices are fine.) In every case the app crashed while trying to read in a file from iCloud, using NSPropertyListSerialization to convert the data to a dictionary. In every case the problem is solved by having the user delete the iCloud data for the app. The same files get synced back in, and everything works fine again.
The specific example I'll use here is from the Mac version, but I've had almost identical crashes on iOS. From the crash report:
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: 0x000000000000000a, 0x0000000101ee2000
VM Regions Near 0x101ee2000:
VM_ALLOCATE 0000000101ee1000-0000000101ee2000 [ 4K] rw-/rwx SM=PRV
--> mapped file 0000000101ee2000-0000000101ee3000 [ 4K] r--/rwx SM=COW /Users/USER/Library/Mobile Documents/PB4R74AA4J~com~junecloud~Notefile/*/*.notefile
shared memory 0000000101ee3000-0000000101ee4000 [ 4K] rw-/rw- SM=SHM
And then:
Thread 7 Crashed:
0 libsystem_c.dylib 0x0000000105157013 bcmp + 19
1 com.apple.CoreFoundation 0x0000000101bbf4b0 __CFBinaryPlistGetTopLevelInfo + 80
2 com.apple.CoreFoundation 0x0000000101bbf36d __CFTryParseBinaryPlist + 93
3 com.apple.CoreFoundation 0x0000000101bbede2 _CFPropertyListCreateWithData + 146
4 com.apple.CoreFoundation 0x0000000101bcbdb0 CFPropertyListCreateWithData + 112
5 com.apple.Foundation 0x0000000101568b89 +[NSPropertyListSerialization propertyListWithData:options:format:error:] + 94
6 com.junecloud.Notefile-Helper 0x000000010107ad06 -[JUNNoteDocument readFromData:ofType:error:] + 64
7 com.apple.AppKit 0x000000010268d507 -[NSDocument readFromURL:ofType:error:] + 546
8 com.apple.AppKit 0x000000010228e3c8 -[NSDocument _initWithContentsOfURL:ofType:error:] + 135
9 com.apple.AppKit 0x000000010228e074 -[NSDocument initWithContentsOfURL:ofType:error:] + 262
10 com.junecloud.Notefile-Helper 0x000000010107cad8 -[JUNSyncDocument initWithFileURL:] + 213
11 com.junecloud.Notefile-Helper 0x0000000101079ec7 -[NotefileAppDelegate documentForURL:] + 68
12 com.junecloud.Notefile-Helper 0x00000001010825cb -[JUNSyncManager documentForURL:] + 76
13 com.junecloud.Notefile-Helper 0x000000010107d43c -[JUNSyncInOperation main] + 1340
14 com.apple.Foundation 0x0000000101563cd2 __NSThread__main__ + 1345
15 libsystem_c.dylib 0x00000001051697a2 _pthread_start + 327
16 libsystem_c.dylib 0x00000001051561e1 thread_start + 13
Thread 7 crashed with X86 Thread State (64-bit):
rax: 0x0000000000000062 rbx: 0x000000000000007b rcx: 0x000000010c2be868 rdx: 0x0000000000000007
rdi: 0x0000000101d1e151 rsi: 0x0000000101ee2000 rbp: 0x000000010c2be810 rsp: 0x000000010c2be7b8
r8: 0x000000010c2be870 r9: 0x0000000000000000 r10: 0x00007ff841c28900 r11: 0x00007ff841c186d8
r12: 0x000000010c2be870 r13: 0x0000000101ee2000 r14: 0x000000010c2beb00 r15: 0x000000010c2be980
rip: 0x0000000105157013 rfl: 0x0000000000010202 cr2: 0x0000000101ee2000
Logical CPU: 2
Here's the relevant bit of code where it's crashing:
- (BOOL)readFromData:(NSData *)data ofType:(NSString *)typeName error:(NSError **)outError {
BOOL success = NO;
NSDictionary *dictionary = nil;
NSError *error = nil;
id plist = [NSPropertyListSerialization propertyListWithData:data
options:NSPropertyListImmutable format:NULL error:&error];
if (plist && [plist isKindOfClass:[NSDictionary class]]) {
dictionary = plist;
} else {
NSLog(#"Error opening document: %# %#",error,[error userInfo]);
if (outError != NULL) *outError = error;
}
// Then it does some things with the dictionary if it's not nil
return success;
}
Am I correct in thinking that NSPropertyListSerialization is just choking on some corrupt data, or is the problem more likely in my own code? If the problem is with NSPropertyListSerialization, is there anything I can do to prevent the app from crashing, and deal with the problem more appropriately?
If the problem is likely to be in my own code, what could I do to track down the cause? This would be much easier if I could duplicate the problem myself, but I've never seen this crash on my own devices, and obviously I can't expect a user to give me access to their iCloud account.
Update As requested, here's a bit of JUNSyncDocument. On iOS this is a UIDocument subclass, on Mac it's an NSDocument subclass.
- (id)initWithFileURL:(NSURL *)url {
#if TARGET_OS_IPHONE
self = [super initWithFileURL:url];
return self;
#else
NSError *error = nil;
if ([[NSFileManager defaultManager] fileExistsAtPath:[url path]]) {
if ((self = [super initWithContentsOfURL:url ofType:[self documentType] error:&error])) {
self.fileURL = url;
self.hasUndoManager = NO;
} else NSLog(#"Error initializing existing document: %# %#",url,error);
} else {
if ((self = [super initWithType:[self documentType] error:&error])) {
self.fileURL = url;
self.hasUndoManager = NO;
} else NSLog(#"Error initializing new document: %#",error);
}
return self;
#endif
}
This seems messy, and I wouldn't be surprised if I'm doing something stupid here. It works fine in most cases though. That gets called from NotefileAppDelegate:
- (JUNSyncDocument *)documentForURL:(NSURL *)url {
JUNNoteDocument *document = [[JUNNoteDocument alloc] initWithFileURL:url];
return document;
}
Which in turn is called by JUNSyncManager:
- (JUNSyncDocument *)documentForURL:(NSURL *)url {
return [self.delegate documentForURL:url];
}
Which is called by JUNSyncInOperation:
JUNSyncDocument *document = [self.delegate documentForURL:self.url];
I just realized I can get rid of that ridiculous delegate chain by using NSClassFromString, but I don't know if that will affect the problem or not.
Looking at the source of __CFTryParseBinaryPlist and __CFBinaryPlistGetTopLevelInfo, which are open source.
It looks like the memcmp (bcmp) that is crashing is at the very beginning where it checks first few bytes of the data for the binary plist header. It wouldn't get that far if CFDataGetLength was <= 8 bytes, so it's not a buffer underflow. It's possible CFDataGetBytePtr returned nil, but I don't see how that could happen if the length was > 8. Most likely, the data pointer has gone invalid.
I could tell more you posted the register contents from the crash report. Also, post the code of how it's creating the data (-[JUNSyncDocument initWithFileURL:] and -[NotefileAppDelegate documentForURL:].)
I have the exact same problem, (UIDocument & NSDocument subclasses, crash when accessing the plist data), although I'm using NSFileWrapper instead.
The mapped file path looks suspicious in your report (unless it's been anonymized by the OS), doesn't appear to be an actual file, but the query string. Isn't it that the NSMetadataQuery is returning incorrect results?
I have no solution so far, still searching.
update
I could debug this problem with a customer, generating custom builds with logging information. Here are my observations:
the crashes happen with different APIs, like NSPropertyListSerialization, CGImageSourceCreateWithURL, and possibly many other.
the accessed file is stored in the iCloud container
It has the following status:
fileExists = YES;
isUbiquitous = YES;
hasNonZeroSize = YES;
isDownloaded = NO;
So it appears as a regular file to most APIs, yet it is not available. When accessed, it makes the app crash.
- the accessed file can be within a file package that has the isDownloaded = YES, although the accessed file itself (within the file package) has isDownloaded = NO.
Work around: check the isDownloaded property for the file prior to accessing its contents. This property is checked using:
-[NSURL getResourceValue:&val forKey:NSURLUbiquitousItemIsDownloadedKey error:&error]
If like me you're using NSFileWrapper to read the UIDocument contents, then you need to have this check in:
-[UIDocument readFromURL:(NSURL *)url error:(NSError *__autoreleasing *)outError]
because the NSFileWrapper won't give you access to the file package NSURL that's needed.
I suspect a problem with the atomicity of iCloud when the document is created. It looks like the file package and its contents are not in sync for their downloaded status, just like if the document directory is made first, and its contents copied to it as 2 distinct operations.
(SEE UPDATE AT THE BOTTOM)
Recently I've started getting a weird and rare crash of my iPhone app when it returns from background. The crash log consists of system calls only:
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00000138
Crashed Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libobjc.A.dylib 0x34c715b0 objc_msgSend + 16
1 CoreFoundation 0x368b7034 _CFXNotificationPost + 1424
2 Foundation 0x34379d8c -[NSNotificationCenter postNotificationName:object:userInfo:] + 68
3 UIKit 0x37ddfec2 -[UIApplication _handleApplicationResumeEvent:] + 1290
4 UIKit 0x37c37d5c -[UIApplication handleEvent:withNewEvent:] + 1288
5 UIKit 0x37c376d0 -[UIApplication sendEvent:] + 68
6 UIKit 0x37c3711e _UIApplicationHandleEvent + 6150
7 GraphicsServices 0x36dea5a0 _PurpleEventCallback + 588
8 CoreFoundation 0x3693b680 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 12
9 CoreFoundation 0x3693aee4 __CFRunLoopDoSources0 + 208
10 CoreFoundation 0x36939cb2 __CFRunLoopRun + 642
11 CoreFoundation 0x368aceb8 CFRunLoopRunSpecific + 352
12 CoreFoundation 0x368acd44 CFRunLoopRunInMode + 100
13 GraphicsServices 0x36de92e6 GSEventRunModal + 70
14 UIKit 0x37c8b2fc UIApplicationMain + 1116
15 [MyAppName] 0x00083d60 main (main.m:20)
16 [MyAppName] 0x00080304 start + 36
This might look like a zombie object being called on UIApplicationWillEnterForegroundNotification or UIApplicationDidBecomeActiveNotification (guessing by _handleApplicationResumeEvent in stack trace and the time when it crashes), but:
None of my classes register for UIApplicationDidBecomeActiveNotification, and only a couple of singletons (that stay alive forever) register for UIApplicationWillEnterForegroundNotification;
I've done some experimenting, and it turns out that posting UIApplicationWillEnterForegroundNotification goes from [UIApplication _sendWillEnterForegroundCallbacks:], and it isn't in the crash log.
For me, all this implies a bug in some library I'm using, or a system bug, and the crash occurred once on iOS 5.1.1 (release build), once on iOS 6.0 (release build) and once on iOS 6.0 (debug build). I scanned every library I'm using and have access to the source code for, and they aren't registering for neither UIApplicationWillEnterForegroundNotification nor UIApplicationDidBecomeActiveNotification. The only library I don't have access to is TestFlight, but the crash occurred on both 1.0 and 1.1 versions of TestFlight, and I've been using the former for quite a while now, without such problems.
So, summing up, I have no idea why has this crash come up and what's it coming from. Any ideas?
UPDATE 1
I've investigated the issue a bit deeper, thanks to DarthMike and matt for their help. By using notification center callback and logging stack trace, I've discovered that this exact stack comes up when and only when UIApplicationResumedNotification notification is fired as a part of returning from background. And guess what - it's some "private" notification and it doesn't have a public identifier counterpart. It doesn't have userInfo and its object is UIApplication (as many other notifications that are posted before this). Obviously I don't use it, neither does any library I have source code for. I can't even find any reasonable mentioning of it in the Internet! I also highly doubt that TestFlight is the culprit, because crash happened during debug too, and I don't "take off" TestFlight in debug mode.
Here's the stack trace for receiving UIApplicationResumedNotification. The offsets are all the same but with a constant byte offset (2 or 4, depending on the library - probably because it's a debug stack tracing, not release):
0 [MyAppName] 0x0016f509 NotificationsCallback + 72
1 CoreFoundation 0x3598ce25 __CFNotificationCenterAddObserver_block_invoke_0 + 124
2 CoreFoundation 0x35911037 _CFXNotificationPost + 1426
3 Foundation 0x333d3d91 -[NSNotificationCenter postNotificationName:object:userInfo:] + 72
4 UIKit 0x36e39ec7 -[UIApplication _handleApplicationResumeEvent:] + 1294
5 UIKit 0x36c91d61 -[UIApplication handleEvent:withNewEvent:] + 1292
6 UIKit 0x36c916d5 -[UIApplication sendEvent:] + 72
7 UIKit 0x36c91123 _UIApplicationHandleEvent + 6154
8 GraphicsServices 0x35e445a3 _PurpleEventCallback + 590
9 CoreFoundation 0x35995683 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 14
10 CoreFoundation 0x35994ee9 __CFRunLoopDoSources0 + 212
11 CoreFoundation 0x35993cb7 __CFRunLoopRun + 646
12 CoreFoundation 0x35906ebd CFRunLoopRunSpecific + 356
13 CoreFoundation 0x35906d49 CFRunLoopRunInMode + 104
14 GraphicsServices 0x35e432eb GSEventRunModal + 74
15 UIKit 0x36ce5301 UIApplicationMain + 1120
16 [MyAppName] 0x000aa603 main + 390
17 [MyAppName] 0x000a41b0 start + 40
NotificationsCallback is an "observer" callback I've added for debug just for now.
Just to prove a point, I've deliberately omitted a removeObserver: call from one of my objects to generate a zombie/exception, and stack trace still included _CFXNotificationPost + 1426 followed by a crash with EXC_BAD_ACCESS in objc_msgSend + 16, just as in my original crash.
So this just means that someone has registered an observer for UIApplicationResumedNotification and haven't removed it before the observer was deallocated. Based on the fact that I never registered for such a notification, I can assume that this crash is not my fault. Still the question remains - whose it is then? I wonder who actually registers for this notification anyway...
UPDATE 2
While I'm still waiting to see if there are any changes with this bug on the new version of my app, I've got another crash on the previous version caused by this. Turns out that whatever registers for UIApplicationResumedNotification, specifies selector _applicationResuming: for it. I doubt that's of any use though.
I had exactly the same stack trace in a crash report from a device running IOS 6.0.1. I managed to reproduce the problem on Simulator through the following pattern:
Put the application in the background
Simulate a memory warning from simulator menu
Bring the application back to the foreground
After a lot of debugging I discovered that the _applicationResuming: message is sent to a UITextField which I am releasing as a reaction to Memory Warning. I tested the same pattern under IOS 5.1 but it didn't cause a crash. For some reason in IOS 6 UITextField registers for ApplicationResumeEvent (maybe not always but after the keyboard has appeared).
My workaround was to remove this object from NSNotificationCenter before releasing it:
[[NSNotificationCenter defaultCenter] removeObserver:self.placeFld];
self.placeFld = nil;
I just ran into this issue and found a solution that did not involve removing notifications. In our case, there was old code that was doing this:
- (void)searchBarTextDidBeginEditing:(UISearchBar *)searchBar
{
[searchBar resignFirstResponder];
// other stuff
}
I do not know why we had this, but it is gone now and the crash is gone. It appears that in this case, resigning first responder while searchBarTextDidBeginEditing is being called orphans a notification on the search bar's text edit field, and then we'd crash as soon as the view controller owning this UISearchBar was deallocated and we did the background / foreground dance.
YMMV
Put a breakpoint on -[NSNotificationCenter postNotificationName:object:userInfo:]. It's trying to send a notification to an object that isn't there any more, or something like that. You may be mismanaging your own notifications or your own objects.
Consider switching to ARC if you are not using it already.
Use the static analyzer. It can find potential memory issues.
Could be many things, but I think checking in code who registers for ANY UIApplication notification would be better. You don't really know which notification triggers the error.
Also, is any object retaining/holding strong reference on the AppDelegate? It may cause some weird retain cycle making this crash happen.
I've never seen such a crash by XCode misbehaviour.
EDIT: Pasting all notifications from header file. may be overkill but some could be sent on app resume/from background
UIKIT_EXTERN NSString *const UIApplicationDidEnterBackgroundNotification NS_AVAILABLE_IOS(4_0);
UIKIT_EXTERN NSString *const UIApplicationWillEnterForegroundNotification NS_AVAILABLE_IOS(4_0);
UIKIT_EXTERN NSString *const UIApplicationDidFinishLaunchingNotification;
UIKIT_EXTERN NSString *const UIApplicationDidBecomeActiveNotification;
UIKIT_EXTERN NSString *const UIApplicationWillResignActiveNotification;
UIKIT_EXTERN NSString *const UIApplicationDidReceiveMemoryWarningNotification;
UIKIT_EXTERN NSString *const UIApplicationWillTerminateNotification;
UIKIT_EXTERN NSString *const UIApplicationSignificantTimeChangeNotification;
UIKIT_EXTERN NSString *const UIApplicationWillChangeStatusBarOrientationNotification; // userInfo contains NSNumber with new orientation
UIKIT_EXTERN NSString *const UIApplicationDidChangeStatusBarOrientationNotification; // userInfo contains NSNumber with old orientation
UIKIT_EXTERN NSString *const UIApplicationStatusBarOrientationUserInfoKey; // userInfo dictionary key for status bar orientation
UIKIT_EXTERN NSString *const UIApplicationWillChangeStatusBarFrameNotification; // userInfo contains NSValue with new frame
UIKIT_EXTERN NSString *const UIApplicationDidChangeStatusBarFrameNotification; // userInfo contains NSValue with old frame
UIKIT_EXTERN NSString *const UIApplicationStatusBarFrameUserInfoKey; // userInfo dictionary key for status bar frame
UIKIT_EXTERN NSString *const UIApplicationLaunchOptionsURLKey NS_AVAILABLE_IOS(3_0); // userInfo contains NSURL with launch URL
UIKIT_EXTERN NSString *const UIApplicationLaunchOptionsSourceApplicationKey NS_AVAILABLE_IOS(3_0); // userInfo contains NSString with launch app bundle ID
UIKIT_EXTERN NSString *const UIApplicationLaunchOptionsRemoteNotificationKey NS_AVAILABLE_IOS(3_0); // userInfo contains NSDictionary with payload
UIKIT_EXTERN NSString *const UIApplicationLaunchOptionsLocalNotificationKey NS_AVAILABLE_IOS(4_0); // userInfo contains a UILocalNotification
UIKIT_EXTERN NSString *const UIApplicationLaunchOptionsAnnotationKey NS_AVAILABLE_IOS(3_2); // userInfo contains object with annotation property list
UIKIT_EXTERN NSString *const UIApplicationProtectedDataWillBecomeUnavailable NS_AVAILABLE_IOS(4_0);
UIKIT_EXTERN NSString *const UIApplicationProtectedDataDidBecomeAvailable NS_AVAILABLE_IOS(4_0);
UIKIT_EXTERN NSString *const UIApplicationLaunchOptionsLocationKey NS_AVAILABLE_IOS(4_0); // app was launched in response to a CoreLocation event.
UIKIT_EXTERN NSString *const UIApplicationLaunchOptionsNewsstandDownloadsKey NS_AVAILABLE_IOS(5_0); // userInfo contains an NSArray of NKAssetDownlo
A few things I do to clear the deck before debugging something an odd crash.
Build Clean (gets rid of local cached files).
Delete the app from Simulator / Device (sometimes XIBs are cached).
Re launch Xcode (there are some weird bugs when Xcode isn't in sync with the current setup).
Then, try again.
So I have an application which uses an NSTimer. The problem is that when the NSTimer runs, my application will crash with EXC_BAD_ACCESS. I only just started with objective-c so I don't know how to properly debug it. If I thought call the -(void)logIn{} with [self logIn]; the application will work.
My code:
.h
#interface DJ_WAppDelegate : NSObject {
NSTimer *loginTimer;
}
-(void)logIn;
#end
.m
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
[self logIn]; // this works
loginTimer = [NSTimer scheduledTimerWithTimeInterval:5.0 target:self selector:#selector(logIn) userInfo:nil repeats:YES]; // this fails
}
- (void)logIn {
NSLog(#"Logging in...");
// if I comment out these 2 lines it works with the NSTimer!?... (I've would have more code below)
NSURL *loginConn = [NSURL URLWithString:[NSString stringWithFormat:#"some-website.com"]];
NSInteger loginReturn = [[NSString stringWithContentsOfURL:loginConn encoding:NSASCIIStringEncoding error:nil] intValue];
// when "loginReturn" return "OK" the timer (loginTimer) will be stopped with: [loginTimer invalidate];
// more code would be below... (which works!)
}
So the problem is with the NSURL it think.
Thanks for helping.
EDIT 1:
Here's the crash stack:
EException Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000020
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Application Specific Information:
objc_msgSend() selector name: respondsToSelector:
Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 libobjc.A.dylib 0x9603bed7 objc_msgSend + 23
1 com.apple.CoreFoundation 0x922ed5f2 _CFStringAppendFormatAndArgumentsAux + 3138
2 com.apple.CoreFoundation 0x922ec979 _CFStringCreateWithFormatAndArgumentsAux + 105
3 com.apple.Foundation 0x9656ebfb -[NSPlaceholderString initWithFormat:locale:arguments:] + 163
4 com.apple.Foundation 0x9656eaae +[NSString stringWithFormat:] + 88
5 com.who.DJ-W 0x00001d56 -[DJ_WAppDelegate logIn] + 116 (DJ_WAppDelegate.m:108)
6 com.apple.Foundation 0x965b08d4 __NSFireTimer + 141
7 com.apple.CoreFoundation 0x922ffadb __CFRunLoopRun + 8059
8 com.apple.CoreFoundation 0x922fd464 CFRunLoopRunSpecific + 452
9 com.apple.CoreFoundation 0x922fd291 CFRunLoopRunInMode + 97
10 com.apple.HIToolbox 0x91646e04 RunCurrentEventLoopInMode + 392
11 com.apple.HIToolbox 0x91646bb9 ReceiveNextEventCommon + 354
12 com.apple.HIToolbox 0x91646a3e BlockUntilNextEventMatchingListInMode + 81
13 com.apple.AppKit 0x9265378d _DPSNextEvent + 847
14 com.apple.AppKit 0x92652fce -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 156
15 com.apple.AppKit 0x92615247 -[NSApplication run] + 821
16 com.apple.AppKit 0x9260d2d9 NSApplicationMain + 574
17 com.who.DJ-W 0x00001c92 start + 54
hope this helps... to find the error
EDIT 2:
With the Zombie Mode on I get this: *** -[CFString respondsToSelector:]: message sent to deallocated instance 0x46d550 I hope this helps.
EDIT 3:
To Ball: Here is the original URL (took away the domain here) /DJW/work.php?user=iBlackbirdi&udid=00000000-0000-1000-80005&key=660e5744e&cmd=slocau&type=get
There are several problems here:
djwLog is a class method so you should call it on the class not the instance
like this: [[self class] djwLog:#"foo bar"]
The URLFromString: method needs the string to contain a valid URL as specified by RFC 1808. Something along the lines of [NSURL URLFromString:#"http://example.com/foo"]
stringWithContentsOfURL:url… is a syncornous method. Unless you have this code running in a separate thread you should not use this. Look at NSURLConnection for a class to asynchronously load data from a URL. Using synchronized calls for this is a bad idea. Always.
intValue returns a signed integer. To get a NSInteger use integerValue. Also if you use stringWithContentsOfURL make sure to check if it's result is nil before calling
integerValue otherwise you might get a result of 0 if the URL call failed or did not return data. A real parser for the API you are calling would be a good idea in any case.
You're calling a class method as if it was an instance method:
[self djwLog:#"Logging in..."];
Since there is no instance-method named djwLog the application crashes. You should either call NSLog directly, make it an instance-method - or preferably make a macro for logging:
#ifdef DEBUG
# define DLog(...) NSLog(#"%s %#", __PRETTY_FUNCTION__, [NSString stringWithFormat:__VA_ARGS__])
#else
# define DLog(...) do { } while (0)
#endif
If you instead of NSLog write DLog - it will only be logging when DEBUG-flag has been defined. In addition to this, it will log the origin of the log message - so you can see which class/method the log entry came from.