没有错误或堆栈跟踪的 iOS 崩溃
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/4810299/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
iOS Crash without Error or Stack Trace
提问by MarkPowell
Having a hard time tracking down a crash in an iPad application. The difficulty really stems from the fact that there is no errors or stack trace present when the application fails. It simply goes away like Keiser Soze, "And like that, poof. He's gone.".
很难追踪 iPad 应用程序中的崩溃。困难真正源于这样一个事实，即应用程序失败时没有错误或堆栈跟踪存在。它就像 Keizer Soze 一样消失了，“就像那样，噗。他走了。”。
I've replicated the crash on both the simulator and the device. There are zero device logs, nothing in the console, etc.
我在模拟器和设备上都复制了崩溃。设备日志为零，控制台中什么也没有，等等。
I know that during the crash some CoreGraphicsoperations are occurring in a background thread. Typically, three or so NSOperations are kicking of some image blends.
我知道在崩溃期间，某些CoreGraphics操作发生在后台线程中。通常，三个左右的 NSOperations 会启动一些图像混合。
The blending consists of CGContext* calls (DrawImage, SetBlendMode, SetAlpha, etc). The NSOperation calls back to a delegate in the main thread to handle the image and set it to UIImage, so it shouldn't be a UI main thread conflict, but I'm not discounting anything at this point.
混合由 CGContext* 调用（DrawImage、SetBlendMode、SetAlpha 等）组成。NSOperation 回调主线程中的一个委托来处理图像并将其设置为UIImage，所以它不应该是 UI 主线程冲突，但我现在不打折任何东西。
Are there some Xcode tricks I'm missing to track down exactly what is happening? Or at least get a better hint of where the problem lies?
我是否缺少一些 Xcode 技巧来准确追踪正在发生的事情？或者至少可以更好地提示问题出在哪里？
EDITI have run the app in Instruments tracking memory usage and see that it is pretty rock steady around 2MB. So, don't think it's a memory issue. But after consideration, this rock steady 2MB seems abnormally low. Is there a chance Instruments is not picking up the CoreGraphics allocations?
编辑我已经在 Instruments 中运行该应用程序来跟踪内存使用情况，并看到它在 2MB 左右非常稳定。所以，不要认为这是一个内存问题。但仔细想想，这稳如磐石的2MB似乎低得离谱。仪器是否有可能不接受 CoreGraphics 分配？
采纳答案by fzwo
For lack of a better solution, and if it isn't obvious, pepper your app with NSLogs to circle where this occurs, then drill deeper from there via breakpoints and/or additional logs.
由于缺乏更好的解决方案，并且如果它不明显，请使用 NSLogs 将您的应用程序添加到发生这种情况的位置，然后通过断点和/或其他日志从那里深入挖掘。
回答by shrishaster
Try reading the registers.
尝试读取寄存器。
Whenever my app crashes without error, in most cases I have found the exception in the registers.
每当我的应用程序无错误地崩溃时，在大多数情况下，我都会在寄存器中发现异常。
First go to Exceptions tab and 'Add Exception Breakpoint' using the + at the bottom left corner.
首先使用左下角的 + 转到“异常”选项卡和“添加异常断点”。
Then when the app crashes click on "0 objc_exception_throw" under Thread 1
然后当应用程序崩溃时，点击线程 1 下的“0 objc_exception_throw”
Finally in the console enter:
最后在控制台输入：
- register read (you should get a list of registers)
po $rax (normally the exception is in 'rax')
(you should see the exception output on the console)
- 寄存器读取（你应该得到一个寄存器列表）
po $rax （通常例外在 'rax' 中）
（您应该会在控制台上看到异常输出）
Hope this helps.
希望这可以帮助。
回答by dragonflyesque
Super late answer, but I've found that using try/catch helps give information when I can't get a stack trace and my application pulls a Keiser Soze.
回答太晚了，但我发现当我无法获得堆栈跟踪并且我的应用程序拉出 Keizer Soze 时，使用 try/catch 有助于提供信息。
@try
{
// suspected code causing crash/errors
}
@catch (NSException *exception)
{
NSLog(@"Exception: %@", exception);
}
回答by Paul Slocum
In my case, it was because I had "Zombie Objects" enabled in the scheme to help find the problem, which was eventually causing it to run out of memory and crash.
就我而言，这是因为我在方案中启用了“僵尸对象”以帮助查找问题，这最终导致它耗尽内存并崩溃。
回答by brainforked
In my case, it was because of bad outlet connection in the storyboard.
Check using breakpoint if viewDidLoadmethod of UIViewControllerto be loaded gets called. If not, check your outlet connections in the storyboard.
就我而言，这是因为情节提要中的插座连接不良。如果要加载的viewDidLoad方法UIViewController被调用，请使用断点检查。如果没有，请检查故事板中的插座连接。
Incorrect connection crashes the app without any error or stack trace.
不正确的连接会导致应用程序崩溃，而不会出现任何错误或堆栈跟踪。
I am wondering what happened to the this class is not key value coding-compliant for the keyerror that used to show in older versions of XCode.
我想知道以前this class is not key value coding-compliant for the key在旧版本的 XCode 中显示的错误发生了什么。
回答by chrs
In my case it was due to an object being released. Normally it would say message sent to deallocated instance or something like that, but it didn't. I checked the iPhone's logs and found this: KERN_INVALID_ADDRESS, which I googled and came across this: KERN_INVALID_ADDRESS
在我的情况下，这是由于一个对象被释放。通常它会说消息发送到释放的实例或类似的东西，但它没有。我检查了 iPhone 的日志，发现了这个：KERN_INVALID_ADDRESS，我在谷歌上搜索并发现了这个：KERN_INVALID_ADDRESS
Enabled zombie objects and found that I tried to use a deallocated instance. It also told me what object it was in the logs afterwards.
启用僵尸对象，发现我尝试使用释放的实例。它还告诉我之后它在日志中是什么对象。
Hope it helps for future visitors.
希望对以后的游客有所帮助。
