问题描述
我的iPad应用程序最近在iOS模拟器中运行时，收到了神秘的SIGKILL信号.这似乎是在应用程序启动后2分钟内发生的，但并非每次都发生.
My iPad application has recently been receiving mysterious SIGKILL signals while running in the iOS Simulator. It seems to happen within 2 minutes of application launch, but not every time.
此回溯指示是否有任何指示，还是我应该尝试删除所有内容，直到找到罪魁祸首?
Does this backtrace indicate anything, or should I try removing things until I find the culprit?
可能涉及一些组件；一个例子是我最近集成了Crashlytics.另一个示例是我正在使用CLGeocoder在MKMapView上绘制位置，这可以解释为什么问题在启动后的某个不确定的时刻发生(以及MapKit出现在其中一个线程中).但是由于没有回溯或记录的明确指示，我在黑暗中射击.
There are some components that could be involved; one example is that I recently integrated Crashlytics. Another example is I'm using CLGeocoder to plot a location on an MKMapView, which could explain why the problem happens at some undetermined point after the launch (and why MapKit appears in one of the threads). But without clearer indication from a backtrace or a log, I'm shooting in the dark.
Xcode 4.3.2;定位到iOS 5.
Xcode 4.3.2; targeting iOS 5.
* thread #1: tid = 0x1f03, 0x9c2c4c22 libsystem_kernel.dylib`mach_msg_trap + 10, stop reason = signal SIGKILL
frame #0: 0x9c2c4c22 libsystem_kernel.dylib`mach_msg_trap + 10
frame #1: 0x9c2c41f6 libsystem_kernel.dylib`mach_msg + 70
frame #2: 0x0178110a CoreFoundation`__CFRunLoopServiceMachPort + 186
frame #3: 0x016e4550 CoreFoundation`__CFRunLoopRun + 1312
frame #4: 0x016e3d84 CoreFoundation`CFRunLoopRunSpecific + 212
frame #5: 0x016e3c9b CoreFoundation`CFRunLoopRunInMode + 123
frame #6: 0x015af7d8 GraphicsServices`GSEventRunModal + 190
frame #7: 0x015af88a GraphicsServices`GSEventRun + 103
frame #8: 0x00394626 UIKit`UIApplicationMain + 1163
frame #9: 0x00001d4d Tablecloth`main + 141 at main.m:16
frame #10: 0x00001cb5 Tablecloth`start + 53
thread #3: tid = 0x2403, 0x9c2c790a libsystem_kernel.dylib`kevent + 10
frame #0: 0x9c2c790a libsystem_kernel.dylib`kevent + 10
frame #1: 0x020b9372 libdispatch.dylib`_dispatch_mgr_invoke + 918
frame #2: 0x020b7be1 libdispatch.dylib`_dispatch_mgr_thread + 53
thread #5: tid = 0x2603, 0x9c2c4c22 libsystem_kernel.dylib`mach_msg_trap + 10
frame #0: 0x9c2c4c22 libsystem_kernel.dylib`mach_msg_trap + 10
frame #1: 0x9c2c41f6 libsystem_kernel.dylib`mach_msg + 70
frame #2: 0x0178110a CoreFoundation`__CFRunLoopServiceMachPort + 186
frame #3: 0x016e45d5 CoreFoundation`__CFRunLoopRun + 1445
frame #4: 0x016e3d84 CoreFoundation`CFRunLoopRunSpecific + 212
frame #5: 0x016e3c9b CoreFoundation`CFRunLoopRunInMode + 123
frame #6: 0x03ede420 WebCore`_ZL12RunWebThreadPv + 560
frame #7: 0x93ebced9 libsystem_c.dylib`_pthread_start + 335
thread #6: tid = 0x2703, 0x9c2c4c22 libsystem_kernel.dylib`mach_msg_trap + 10
frame #0: 0x9c2c4c22 libsystem_kernel.dylib`mach_msg_trap + 10
frame #1: 0x9c2c41f6 libsystem_kernel.dylib`mach_msg + 70
frame #2: 0x0178110a CoreFoundation`__CFRunLoopServiceMachPort + 186
frame #3: 0x016e45d5 CoreFoundation`__CFRunLoopRun + 1445
frame #4: 0x016e3d84 CoreFoundation`CFRunLoopRunSpecific + 212
frame #5: 0x016e3c9b CoreFoundation`CFRunLoopRunInMode + 123
frame #6: 0x00d94e30 Foundation`+[NSURLConnection(Loader) _resourceLoadLoop:] + 398
frame #7: 0x00ca64d6 Foundation`-[NSThread main] + 76
frame #8: 0x00ca6447 Foundation`__NSThread__main__ + 1258
frame #9: 0x93ebced9 libsystem_c.dylib`_pthread_start + 335
thread #7: tid = 0x2803, 0x9c2c4c22 libsystem_kernel.dylib`mach_msg_trap + 10
frame #0: 0x9c2c4c22 libsystem_kernel.dylib`mach_msg_trap + 10
frame #1: 0x9c2c41f6 libsystem_kernel.dylib`mach_msg + 70
frame #2: 0x0178110a CoreFoundation`__CFRunLoopServiceMachPort + 186
frame #3: 0x016e45d5 CoreFoundation`__CFRunLoopRun + 1445
frame #4: 0x016e3d84 CoreFoundation`CFRunLoopRunSpecific + 212
frame #5: 0x016e3c9b CoreFoundation`CFRunLoopRunInMode + 123
frame #6: 0x0012286b MapKit`MKNormalizedPointForLayer + 30057
frame #7: 0x00ca64d6 Foundation`-[NSThread main] + 76
frame #8: 0x00ca6447 Foundation`__NSThread__main__ + 1258
frame #9: 0x93ebced9 libsystem_c.dylib`_pthread_start + 335
thread #8: tid = 0x2903, 0x9c2c6b42 libsystem_kernel.dylib`select$DARWIN_EXTSN + 10
frame #0: 0x9c2c6b42 libsystem_kernel.dylib`select$DARWIN_EXTSN + 10
frame #1: 0x017157cb CoreFoundation`__CFSocketManager + 939
frame #2: 0x93ebced9 libsystem_c.dylib`_pthread_start + 335
thread #9: tid = 0x2a03, 0x9c2c702e libsystem_kernel.dylib`__workq_kernreturn + 10
frame #0: 0x9c2c702e libsystem_kernel.dylib`__workq_kernreturn + 10
frame #1: 0x93ebeccf libsystem_c.dylib`_pthread_wqthread + 773
Crashlytics支持团队帮助我调试了该问题，似乎要解决的问题是使用Simulator应用程序中的重置内容和设置…"菜单项.目前尚不清楚为什么会发生这种情况，但是我不再遇到调试中断的情况.
The Crashlytics support team helped me debug this, and the thing that seemed to fix it was to use the "Reset Content and Settings…" menu item in the Simulator app. It's not clear why exactly this happened, but I'm not getting the debugging interruptions anymore.
推荐答案
SIGKILL通常建议您被操作系统杀死.您的控制台日志将比堆栈跟踪更有用.如果是在设备上，我会怀疑使用了过多的内存，但这在模拟器中是不太可能的.另一个常见的SIGKILL是如果您阻塞主线程的时间太长，所以我会寻找(尽管我不认为模拟器提供了那个主线程).
SIGKILL generally suggests that you were killed by the OS. Your console logs are going to be more useful than the stack traces. If it were on device, I would suspect using too much memory, but that's very unlikely in the simulator. The other common SIGKILL is if you block your main thread too long, so I'd look for that (though I didn't think the simulator provided that one).
但是最好的看方法是在运行日志中.
But your best place to look is in the run log.
这篇关于iPad中的神秘SIGKILL应用程序在模拟器中运行的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！