iOS 崩溃,没有错误或堆栈跟踪
很难追踪 iPad 应用程序中的崩溃情况。困难实际上源于应用程序失败时不存在错误或堆栈跟踪的事实。它就像凯泽·索兹(Keizer Soze)一样消失了,“就这样,噗。他走了。”。
我已经在模拟器和设备上复制了崩溃。设备日志为零,控制台中没有任何内容,等等。
我知道在崩溃期间,后台线程中发生了一些 CoreGraphics 操作。通常,三个左右的 NSOperations 会引发一些图像混合。
混合由 CGContext* 调用(DrawImage、SetBlendMode、SetAlpha 等)组成。 NSOperation 回调主线程中的委托来处理图像并将其设置为 UIImage
,因此它不应该是 UI 主线程冲突,但此时我不会打折扣。
我是否缺少一些 Xcode 技巧来准确追踪正在发生的情况?或者至少更好地提示问题出在哪里?
编辑 我已经在 Instruments 中运行该应用程序来跟踪内存使用情况,发现它非常稳定在 2MB 左右。所以,不要认为这是内存问题。但仔细想想,这个稳定的2MB似乎低得异常。 Instruments 是否有可能没有获取 CoreGraphics 分配?
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.".
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 CoreGraphics
operations are occurring in a background thread. Typically, three or so NSOperations are kicking of some image blends.
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.
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?
EDIT I 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?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(6)
就我而言,这是由于释放了一个对象。通常它会说消息已发送到已释放的实例或类似的内容,但事实并非如此。我检查了iPhone的日志,发现了这个:KERN_INVALID_ADDRESS,我用谷歌搜索并发现了这个:KERN_INVALID_ADDRESS
启用僵尸对象并发现我尝试使用已释放的实例。之后它还告诉我日志中的对象是什么。
希望它对未来的访客有所帮助。
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
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.
尝试读取寄存器。
每当我的应用程序崩溃而没有错误时,在大多数情况下我都会在寄存器中找到异常。
首先转到“异常”选项卡,然后使用左下角的 + 来“添加异常断点”。

然后,当应用程序崩溃时,单击线程 1 下的“0 objc_exception_throw”

最后在控制台中输入:
register read
(您应该获得寄存器列表)
po $rax(通常例外在“rax”中)
(您应该在控制台上看到异常输出)
希望这有帮助。
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

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)
Hope this helps.
由于缺乏更好的解决方案,并且如果情况不明显,请在您的应用程序中添加 NSLogs 以圈出发生这种情况的位置,然后通过断点和/或其他日志从那里进行更深入的钻取。
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.
超级晚的答案,但我发现当我无法获取堆栈跟踪并且我的应用程序拉取 Keizer Soze 时,使用 try/catch 有助于提供信息。
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.
就我而言,这是因为故事板中的插座连接不良。
使用断点检查要加载的
UIViewController
的viewDidLoad
方法是否被调用。如果没有,请检查故事板中的插座连接。不正确的连接会导致应用程序崩溃,而不会出现任何错误或堆栈跟踪。
我想知道旧版本的 XCode 中经常出现的
this class is not key valuecoding-dependent for the key
错误发生了什么。In my case, it was because of bad outlet connection in the storyboard.
Check using breakpoint if
viewDidLoad
method ofUIViewController
to be loaded gets called. If not, check your outlet connections in the storyboard.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 key
error that used to show in older versions of XCode.就我而言,这是因为我在方案中启用了“僵尸对象”来帮助查找问题,这最终导致它耗尽内存并崩溃。
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.