iOS应用程式在恢复时崩溃 [英] iOS app crashes on resuming

问题描述

（在底部查看更新）

最近我开始遇到一个奇怪而罕见的iPhone应用程序崩溃从背景。崩溃日志仅包含系统调用：

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

这可能看起来像在上调用的僵尸对象UIApplicationWillEnterForegroundNotification 或 UIApplicationDidBecomeActiveNotification （在堆栈跟踪中查找 _handleApplicationResumeEvent ），但是：

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:

1. 我的课程没有注册 UIApplicationDidBecomeActiveNotification ，只有几个单身注册 UIApplicationWillEnterForegroundNotification ;


2. 我做了一些实验，结果发布 UIApplicationWillEnterForegroundNotification 从 [UIApplication _sendWillEnterForegroundCallbacks：] ，并不在崩溃日志中。



1. None of my classes register for UIApplicationDidBecomeActiveNotification, and only a couple of singletons (that stay alive forever) register for UIApplicationWillEnterForegroundNotification;
2. I've done some experimenting, and it turns out that posting UIApplicationWillEnterForegroundNotification goes from [UIApplication _sendWillEnterForegroundCallbacks:], and it isn't in the crash log.

对我来说，这意味着我正在使用的库中的一个错误，或者一个系统错误，崩溃在iOS 5.1.1（发布版本）上发生一次，一次在iOS 6.0发布版），一次在iOS 6.0（调试版）。我扫描了我使用的每个库，并且可以访问源代码，并且他们既不注册 UIApplicationWillEnterForegroundNotification 也不注册 UIApplicationDidBecomeActiveNotification 。我唯一不能访问的库是TestFlight，但崩溃发生在TestFlight的1.0和1.1版本，我已经使用前一段时间了，没有这样的问题。
所以，总结起来，我不知道为什么这个崩溃来了，它是从什么来的。任何想法？

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?

更新1

更深，感谢DarthMike和亚光的帮助。通过使用通知中心回调和记录堆栈跟踪，我发现这个确切的堆栈，当且仅当 UIApplicationResumedNotification 通知作为从后台返回的一部分被触发。猜测是什么 - 这是一些私人通知，它没有公共标识符对应。它没有 userInfo ，它的对象是 UIApplication （像之前发布的许多其他通知）。显然我不使用它，也没有任何库我有源代码。我甚至在互联网上找不到任何合理的提法！我也很怀疑TestFlight是罪魁祸首，因为崩溃发生在调试过程中，我没有在调试模式脱机TestFlight。

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.

这里是堆栈跟踪用于接收 UIApplicationResumedNotification 。偏移都是相同的，但是有一个常量的字节偏移（2或4，取决于库 - 可能是因为它是一个调试堆栈跟踪，不发布）：

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

通知Callback是一个观察者

NotificationsCallback is an "observer" callback I've added for debug just for now.

为了证明一点，我故意省略了一个 removeObserver：调用从我的一个对象生成一个僵尸/异常，堆栈跟踪仍然包括 _CFXNotificationPost + 1426 后跟与 EXC_BAD_ACCESS 在 objc_msgSend + 16 中，就像在我原来的崩溃。
所以这只是意味着有人注册了 UIApplicationResumedNotification 的观察者，并且在观察者被释放之前没有删除它。基于我从未注册这样的通知的事实，我可以假设这次崩溃不是我的错。仍然的问题仍然是 - 那么呢？我不知道谁实际注册了此通知...

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

虽然我还在等待看看这个bug在我的应用程序的新版本是否有任何更改，我有另一个崩溃在以前的版本引起的。事实证明，对于 UIApplicationResumedNotification 的任何寄存器，指定选择器 _applicationResuming：。我怀疑这是任何用途。

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 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
}

我不知道为什么我们有，但它现在走了，崩溃消失了。看起来在这种情况下，辞职第一个响应者，而searchBarTextDidBeginEditing被称为孤儿在搜索栏的文本编辑字段上的通知，然后我们会崩溃，只要拥有此UISearchBar的视图控制器被释放，我们做了背景/前台跳舞。

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

这篇关于iOS应用程式在恢复时崩溃的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！