在几乎没有信息的情况下调试 iPad 设备崩溃
我从设备中提取的 iPad 崩溃中获取了以下堆栈跟踪。这是从用户的 iPad 上提取的,我不知道当它崩溃时他们在做什么。我如何获得有关应用程序崩溃的原因/位置的更多信息并修复它?
Uncaught C++ Exception Stack trace: 0 - 0 MyApp 0x00005ac1 _Z16TerminateHandlerv + 24 1 - 1 libstdc++.6.dylib 0x33814e3d _ZN10__cxxabiv111__terminateEPFvvE + 52 2 - 2 libstdc++.6.dylib 0x33814e91 _ZSt9terminatev + 16 3 - 3 libstdc++.6.dylib 0x33814f61 __cxa_throw + 84 4 - 4 libobjc.A.dylib 0x3441dc8b objc_exception_throw + 70 5 - 5 Foundation 0x3645192b __NSThreadPerformPerform + 654 6 - 6 CoreFoundation 0x34e16a79 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 12 7 - 7 CoreFoundation 0x34e1875f __CFRunLoopDoSources0 + 382 8 - 8 CoreFoundation 0x34e194eb __CFRunLoopRun + 230 9 - 9 CoreFoundation 0x34da9ec3 CFRunLoopRunSpecific + 230 10 - 10 CoreFoundation 0x34da9dcb CFRunLoopRunInMode + 58 11 - 11 GraphicsServices 0x339d041f GSEventRunModal + 114 12 - 12 GraphicsServices 0x339d04cb GSEventRun + 62 13 - 13 UIKit 0x33a07d69 -[UIApplication _run] + 404 14 - 14 UIKit 0x33a05807 UIApplicationMain + 670 15 - 15 MyApp 0x000036af main + 70 16 - 16 MyApp 0x00003664 start + 40
I'm getting the following stack trace from an iPad crash pulled from the device. This was pulled from a user's iPad and I don't know what they were doing when it crashed. How would I get more info on why/where the app is crashing and fix it?
Uncaught C++ Exception Stack trace: 0 - 0 MyApp 0x00005ac1 _Z16TerminateHandlerv + 24 1 - 1 libstdc++.6.dylib 0x33814e3d _ZN10__cxxabiv111__terminateEPFvvE + 52 2 - 2 libstdc++.6.dylib 0x33814e91 _ZSt9terminatev + 16 3 - 3 libstdc++.6.dylib 0x33814f61 __cxa_throw + 84 4 - 4 libobjc.A.dylib 0x3441dc8b objc_exception_throw + 70 5 - 5 Foundation 0x3645192b __NSThreadPerformPerform + 654 6 - 6 CoreFoundation 0x34e16a79 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 12 7 - 7 CoreFoundation 0x34e1875f __CFRunLoopDoSources0 + 382 8 - 8 CoreFoundation 0x34e194eb __CFRunLoopRun + 230 9 - 9 CoreFoundation 0x34da9ec3 CFRunLoopRunSpecific + 230 10 - 10 CoreFoundation 0x34da9dcb CFRunLoopRunInMode + 58 11 - 11 GraphicsServices 0x339d041f GSEventRunModal + 114 12 - 12 GraphicsServices 0x339d04cb GSEventRun + 62 13 - 13 UIKit 0x33a07d69 -[UIApplication _run] + 404 14 - 14 UIKit 0x33a05807 UIApplicationMain + 670 15 - 15 MyApp 0x000036af main + 70 16 - 16 MyApp 0x00003664 start + 40
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
您可以尝试两件事:
有时应用程序会崩溃,调试器会以完全不同的方法停止。在 xcode 运行设置中启用“guard malloc”(在 xcode4 中的方案下),在调试器中运行应用程序直到它崩溃,然后看看是否显示了应该归咎于哪个方法。
如果没有,最好的选择是在调试器中运行应用程序并导致崩溃发生。尝试一切,模拟无处不在的内存警告,使用应用程序的每个功能,尝试应用程序中所有可能的路径组合。询问用户他们认为自己在做什么可能会缩小范围。
Two things you might try:
Somtimes apps crash and the debugger stops on a completely different method. Enable "guard malloc" in the xcode run settings (under schemes in xcode4), run the app in the debugger utill it crashes, and see if that shows you which method is to blame.
If not, your best bet is to run the app in the debugger and make the crash happen. Try everything, simulate memory warnings everywhere, use every feature of the app, try every possible combination of paths through the app. Asking the user what they think they were doing might narrow it down some.