[英]Intermittent SIGABRT and SIGSEGV crashes in iOS app
我一直注意到我的iOS应用程序中的一些崩溃问题。 但是,我无法观察到我的任何设备发生的崩溃,因此我依赖于用户发送给我的崩溃日志。 这是3个看起来类似的符号化崩溃日志的示例(我在线程0堆栈跟踪之后切断了所有内容,其余崩溃日志似乎没有任何有用的信息):
崩溃日志1:
Date/Time: 2012-11-07 16:40:21 +0000
OS Version: iPhone OS 6.0 (10A403)
Report Version: 104
Exception Type: SIGABRT
Exception Codes: #0 at 0x3c210350
Crashed Thread: 0
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x00011350 __pthread_kill + 8
1 libsystem_c.dylib 0x0006b973 abort + 95
2 libc++abi.dylib 0x00003d4f abort_message + 75
3 libc++abi.dylib 0x00000ff9 default_terminate() + 25
4 libobjc.A.dylib 0x00008a77 _objc_terminate() + 147
5 libc++abi.dylib 0x0000107b safe_handler_caller(void (*)()) + 79
6 libc++abi.dylib 0x00001114 std::terminate() + 20
7 libc++abi.dylib 0x00002599 __cxa_current_exception_type + 1
8 libobjc.A.dylib 0x000089d1 objc_exception_rethrow + 13
9 CoreFoundation 0x00008f21 CFRunLoopRunSpecific + 457
10 CoreFoundation 0x00008d49 CFRunLoopRunInMode + 105
11 GraphicsServices 0x000052eb GSEventRunModal + 75
12 UIKit 0x00057301 UIApplicationMain + 1121
13 TheApp 0x000c7c17 -[StatusEditViewController grabData] (StatusEditViewController.m:75)
崩溃日志2:
Date/Time: 2012-10-25 14:46:23 +0000
OS Version: iPhone OS 5.1.1 (9B206)
Report Version: 104
Exception Type: SIGABRT
Exception Codes: #0 at 0x35d1b32c
Crashed Thread: 0
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x35d1b32c __pthread_kill + 8
1 libsystem_c.dylib 0x34efc29f abort + 94
2 libc++abi.dylib 0x35513f6b abort_message + 46
3 libc++abi.dylib 0x3551134d _ZL17default_terminatev + 24
4 libobjc.A.dylib 0x338c9357 _objc_terminate + 146
5 libc++abi.dylib 0x355113c5 _ZL19safe_handler_callerPFvvE + 76
6 libc++abi.dylib 0x35511451 _ZdlPv + 0
7 libc++abi.dylib 0x35512825 __cxa_current_exception_type + 0
8 libobjc.A.dylib 0x338c92a9 objc_exception_rethrow + 12
9 CoreFoundation 0x35bfb50d CFRunLoopRunSpecific + 404
10 CoreFoundation 0x35bfb36d CFRunLoopRunInMode + 104
11 GraphicsServices 0x33996439 GSEventRunModal + 136
12 UIKit 0x333d3cd5 UIApplicationMain + 1080
13 TheApp 0x000c7c17 -[StatusEditViewController grabData] (StatusEditViewController.m:75)
尤其令人困惑的是崩溃日志3:
Date/Time: 2012-11-12 11:00:21 +0000
OS Version: iPhone OS 5.1.1 (9B206)
Report Version: 104
Exception Type: SIGSEGV
Exception Codes: SEGV_ACCERR at 0x7142fa3c
Crashed Thread: 0
Thread 0 Crashed:
0 libobjc.A.dylib 0x314d8f78 objc_msgSend + 15
1 UIKit 0x31c1d6d7 -[UIPrintPanelViewController dismissPrintPanel:animated:] + 50
2 UIKit 0x31c920dd __73-[UIPopoverController _completionBlockForDismissalWhenNotifyingDelegate:]_block_invoke_0 + 284
3 UIKit 0x318db4db -[UIViewAnimationBlockDelegate _didEndBlockAnimation:finished:context:] + 214
4 UIKit 0x318d5aab -[UIViewAnimationState sendDelegateAnimationDidStop:finished:] + 470
5 UIKit 0x318db3d5 -[UIViewAnimationState animationDidStop:finished:] + 52
6 QuartzCore 0x3552ec2f _ZN2CA5Layer23run_animation_callbacksEPv + 202
7 libdispatch.dylib 0x34838ee7 _dispatch_main_queue_callback_4CF$VARIANT$mp + 194
8 CoreFoundation 0x316662ad __CFRunLoopRun + 1268
9 CoreFoundation 0x315e94a5 CFRunLoopRunSpecific + 300
10 CoreFoundation 0x315e936d CFRunLoopRunInMode + 104
11 GraphicsServices 0x32ac2439 GSEventRunModal + 136
12 UIKit 0x318eecd5 UIApplicationMain + 1080
13 TheApp 0x000c7c17 -[StatusEditViewController grabData] (StatusEditViewController.m:75)
如您所见,这些崩溃日志在线程0堆栈跟踪中都有14个条目(不确定是否是巧合),并且底部的项与应用程序中的同一行代码相同。 这行代码非常简单,它只是调用一个类方法,该类方法在以下情况下显示UIAlertView:在编辑视图控制器上输入的数据无效,并且传入的字符串是常量,而不是变量。
在崩溃日志3中,有对UIPrintPanelViewController的引用,尽管我的应用程序确实具有打印功能,但是无法同时打开打印弹出窗口和状态编辑弹出窗口,因此我不确定为什么会这样说它在崩溃期间试图关闭打印面板。
有人对我如何解决此问题有任何提示或策略吗? (我正在针对最新的iOS SDK和Xcode 4.5.1。进行构建。)
编辑:这是应用程序中令人反感的代码行:
[Utils msgBox:@"Entry required" message:@"Please enter a value for the Status field before tapping Save."];
由于这可能是下一条注释的主题,因此这是Utils.m中msgBox的类方法:
+ (void)msgBox:(NSString *)inTitle message:(NSString *)inMessage
{
UIAlertView *alert = [[UIAlertView alloc]
initWithTitle:inTitle
message:inMessage
delegate:nil
cancelButtonTitle:@"OK"
otherButtonTitles:nil];
[alert show];
[alert release];
}
由于堆栈跟踪没有显示有关进入Utils类的任何记录,因此我猜测在调用类方法之前发生了某些情况。
之所以得到这个,是因为您打电话给[alert show];
从后台线程(来自grabData
)。
最快的解决方案:
dispatch_async(dispatch_get_main_queue(), ^{
[alert show];
});
我知道您(一年前)已经解决了它,但是也许它将对其他人(例如我)有所帮助。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.