Vla*_*hin 10 crash objective-c ios
(见底部更新)
最近,当我的iPhone应用程序从后台返回时,我开始得到一个奇怪而罕见的崩溃.崩溃日志仅包含系统调用:
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
Run Code Online (Sandbox Code Playgroud)
这可能看起来像是一个被调用的僵尸对象UIApplicationWillEnterForegroundNotification或UIApplicationDidBecomeActiveNotification(通过_handleApplicationResumeEvent堆栈跟踪和崩溃的时间猜测),但是:
UIApplicationDidBecomeActiveNotification,只有几个单身人士(永远活着)注册UIApplicationWillEnterForegroundNotification;UIApplicationWillEnterForegroundNotification从云[UIApplication _sendWillEnterForegroundCallbacks:],它是不是在崩溃日志.对我来说,这一切都意味着我正在使用的某个库中存在一个错误,或系统错误,并且在iOS 5.1.1(发布版本)上发生过一次崩溃,一次在iOS 6.0(发布版本)上发生,一次发生在iOS 6.0上( debug build).我扫描我使用和访问的源代码每个库,和他们没有报名参加既不UIApplicationWillEnterForegroundNotification也没有UIApplicationDidBecomeActiveNotification.我无法访问的唯一库是TestFlight,但崩溃发生在1.0和1.1版本的TestFlight上,而且我已经使用前者已经有一段时间了,没有这样的问题.所以,总结一下,我不知道为什么会出现这种崩溃,它是什么来的.有任何想法吗?
更新1
我已经对这个问题进行了更深入的调查,感谢DarthMike和matt的帮助.通过使用通知中心回调和记录堆栈跟踪,我发现只有当UIApplicationResumedNotification通知作为从后台返回的一部分被触发时,才会出现这个确切的堆栈.猜猜是什么 - 它是一些"私人"通知,它没有公共标识符对应物.它没有userInfo,它的对象是UIApplication(在此之前发布的许多其他通知).显然我不使用它,也没有任何库我有源代码.我甚至无法在互联网上找到任何合理的提及!我也非常怀疑TestFlight是罪魁祸首,因为在调试期间也发生了崩溃,而且我没有在调试模式下"脱掉"TestFlight.
这是接收的堆栈跟踪UIApplicationResumedNotification.偏移量都是相同的但具有恒定的字节偏移量(2或4,取决于库 - 可能是因为它是调试堆栈跟踪,而不是释放):
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
Run Code Online (Sandbox Code Playgroud)
NotificationsCallback是我刚刚为调试添加的"观察者"回调.
只是为了证明这一点,我故意省略了removeObserver:从我的对象,生成僵尸/异常,堆栈跟踪仍然包括了一个电话_CFXNotificationPost + 1426,随后用碰撞EXC_BAD_ACCESS中objc_msgSend + 16,就像在我原来的崩溃.所以这只是意味着有人UIApplicationResumedNotification在观察者被解除分配之前注册了观察者并且没有删除它.基于我从未注册过此类通知的事实,我可以认为这次崩溃不是我的错.问题仍然存在 - 那是谁呢?我想知道究竟谁注册了这个通知......
更新2
虽然我还在等待我的应用程序的新版本上的这个错误是否有任何变化,但是由于此原因导致我的先前版本出现了另一次崩溃.事实证明,无论寄存器是什么UIApplicationResumedNotification,都指定_applicationResuming:它的选择器.我怀疑这有什么用处.
小智 6
我在运行IOS 6.0.1的设备的崩溃报告中有完全相同的堆栈跟踪.我设法通过以下模式在Simulator上重现问题:
经过大量的调试后,我发现_applicationResuming:消息被发送到UITextField,我将其作为对Memory Warning的反应而发布.我在IOS 5.1下测试了相同的模式,但它没有导致崩溃.由于某些原因,IOS 6 UITextField注册了ApplicationResumeEvent(可能并不总是在键盘出现之后).
我的解决方法是在释放它之前从NSNotificationCenter中删除此对象:
[[NSNotificationCenter defaultCenter] removeObserver:self.placeFld];
self.placeFld = nil;
Run Code Online (Sandbox Code Playgroud)
我刚刚遇到这个问题并找到了一个不涉及删除通知的解决方案。在我们的例子中,有旧代码正在执行此操作:
- (void)searchBarTextDidBeginEditing:(UISearchBar *)searchBar
{
[searchBar resignFirstResponder];
// other stuff
}
Run Code Online (Sandbox Code Playgroud)
我不知道为什么会出现这种情况,但现在它已经消失了,崩溃也消失了。看来在这种情况下,在调用 searchBarTextDidBeginEditing 时放弃第一响应者会孤立搜索栏文本编辑字段上的通知,然后一旦拥有此 UISearchBar 的视图控制器被释放并且我们执行了后台/前台操作,我们就会崩溃舞蹈。
青年MMV
| 归档时间: |
|
| 查看次数: |
8422 次 |
| 最近记录: |