iPhone 崩溃且“无回溯”
我的 iPhone 应用程序最近被 App Store 拒绝，“因为它在启动时崩溃”。但是，我无法重现此崩溃。该应用程序在模拟器和具有 Apple 测试过的相同硬件和软件的设备（运行 iOS 4 的 iPhone 3.1）上都能完美运行。他们发给我的崩溃日志显示“没有可用的回溯”，所以我无处可查我的代码。这是一个例子：
Incident Identifier: [...]
CrashReporter Key: [...]
Hardware Model: iPhone3,1
Process: [MyApp] [1172]
Path: /var/mobile/Applications/[...]-3F1B-4504-A572-[...]/[MyApp].app/[MyApp]
Identifier: [MyApp]
Version: ??? (???)
Code Type: ARM (Native)
Parent Process: launchd [1]
Date/Time: 2010-07-08 [...]
OS Version: iPhone OS 4.0 (8A293)
Report Version: 104
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0xfe42c648
Highlighted Thread: 0
Backtrace not available
Unknown thread crashed with ARM Thread State:
r0: 0x00002388 r1: 0x00000000 r2: 0x3e2b47c8 r3: 0x00000108
r4: 0x2fe00000 r5: 0x00000000 r6: 0x00000000 r7: 0x00000000
r8: 0x2ffffb48 r9: 0x2fffecfc r10: 0x00000000 r11: 0x00000000
ip: 0x00000010 sp: 0x2ffffb4c lr: 0x2fe08907 pc: 0xfe42c648
cpsr: 0x40000010
Binary Images:
0x1000 - 0x78fff +[MyApp] armv7 <23af3d265c3086eaceb51cc649eb794f> /var/mobile/Applications/[...]-3F1B-4504-A572-[...]/[MyApp].app/[MyApp]
0x2fe00000 - 0x2fe26fff dyld armv7 <697ae459733a7f0b6c439b21ba62b110> /usr/lib/dyld
[many more libraries...]
我怎样才能开始调试这个？这有可能是构建问题而不是编码错误吗？我可以从崩溃报告的“ARM 线程状态”或“二进制图像”部分中提取任何有用的信息吗？
谢谢！
*更新：* 我第一次在另一台运行 iOS 4 的 iPhone 上安装该应用程序，但仍然无法重现崩溃。我开始认为这是构建时参数（例如库或目标版本）的问题。根据崩溃报告，我的应用程序的代码是否可能被执行？
My iPhone app was recently rejected from the App Store "because it crashes on launch". However, I cannot reproduce this crash. The app works perfectly on both the simulator and a device with the same hardware and software Apple tested it on (iPhone 3.1 running iOS 4). The crash logs they sent me say "No Backtrace Available", so I have nowhere to look in my code. Here's an example:
Incident Identifier: [...]
CrashReporter Key: [...]
Hardware Model: iPhone3,1
Process: [MyApp] [1172]
Path: /var/mobile/Applications/[...]-3F1B-4504-A572-[...]/[MyApp].app/[MyApp]
Identifier: [MyApp]
Version: ??? (???)
Code Type: ARM (Native)
Parent Process: launchd [1]
Date/Time: 2010-07-08 [...]
OS Version: iPhone OS 4.0 (8A293)
Report Version: 104
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0xfe42c648
Highlighted Thread: 0
Backtrace not available
Unknown thread crashed with ARM Thread State:
r0: 0x00002388 r1: 0x00000000 r2: 0x3e2b47c8 r3: 0x00000108
r4: 0x2fe00000 r5: 0x00000000 r6: 0x00000000 r7: 0x00000000
r8: 0x2ffffb48 r9: 0x2fffecfc r10: 0x00000000 r11: 0x00000000
ip: 0x00000010 sp: 0x2ffffb4c lr: 0x2fe08907 pc: 0xfe42c648
cpsr: 0x40000010
Binary Images:
0x1000 - 0x78fff +[MyApp] armv7 <23af3d265c3086eaceb51cc649eb794f> /var/mobile/Applications/[...]-3F1B-4504-A572-[...]/[MyApp].app/[MyApp]
0x2fe00000 - 0x2fe26fff dyld armv7 <697ae459733a7f0b6c439b21ba62b110> /usr/lib/dyld
[many more libraries...]
How can I begin debugging this? Is it possible this is a build issue rather than a coding bug? And can I extract any useful information from the "ARM Thread State" or the "Binary Images" portions of the crash report?
Thanks!
*update: * I have installed the app for the first time on another iPhone running iOS 4 and still cannot reproduce the crash. I'm beginning to think this is an issue with build-time parameters such as libraries or targeted versions. Based on the crash report, is it likely that any of my application's code was executed?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
段错误不太可能是构建错误。要重现此问题，请尝试在运行项目之前清除 iPhone 模拟器上保存的所有信息；您可能假设 NSUserDefaults 中存在某些条目，这些条目存在于您自己的 iPhone 上，但在默认安装中不可用。如果这不能重现问题，那么您应该为每个组件创建单元测试，一次排除每个组件作为故障原因。最终，除了失败的真正原因之外，您将排除所有失败原因。
A segfault is unlikely to be a build error. To reproduce this problem, try clearing out any saved information on the iPhone simulator before running the project; it is possible that you are assuming the existence of certain entries in NSUserDefaults that are present on your own iPhone, but which would not be available on a default installation. If that doesn't reproduce the problem, then you should create unit tests for each of your components, ruling out each component at a time as the cause of failure. Eventually, you will have ruled out every cause of failure except for the true cause of failure.
我永远无法重现崩溃的情况。我弄乱了一些构建参数并重新提交并获得了批准。
I was never able to reproduce the crash. I messed with a few build params and resubmitted and it was approved.
请参阅技术说明 TN2151：了解和分析 iPhone 操作系统应用程序崩溃报告。 符号通常可以帮助您追踪崩溃的根源，但由于没有回溯，在这种情况下它可能没有帮助。
不要在模拟器上进行测试。模拟器构建和设备构建是针对两个不同硬件的完全独立的编译。仅仅因为它在模拟器上运行，就不会告诉您任何有关设备故障的信息。
请记住，Apple 会对应用程序进行压力测试，例如在 iOS4 上启动应用程序，而其他应用程序会占用大部分内存。您也需要在测试设备上执行此操作。
您很可能必须将测试设备恢复为默认设置才能复制苹果所做的测试。然后在启动您自己的应用程序之前打开所有可能的应用程序。
See Technical Note TN2151:Understanding and Analyzing iPhone OS Application Crash Reports. Symbolication would normally help you track down the source of a crash but since there is no backtrace it may not help in this instance.
Don't bother testing on the simulator. The simulator build and the device build are wholly separate compiles for two different pieces of hardware. Just because it runs on simulator tells you nothing about a failure on device.
Remember that Apple will stress test the app by doing things like launching it on iOS4 with other apps eating up most of the memory. You will need to do that as well on your test device.
You will most likely have to wipe your test device back to defaults to replicate the test Apple does. Then open every possible app before launching your own.
您可以从 ARM 线程状态获取一些信息。 PC 寄存器是唯一包含崩溃报告所抱怨的无效地址的寄存器。这意味着您的应用程序尝试在该地址执行代码。
SIGSEGV 表示有问题的地址无效。系统没有设置该地址的内存页。
我不认为iOS会允许你简单地从任何地址执行代码，但当函数返回时，堆栈帧可能已损坏并且返回地址无效。这支持“回溯不可用”问题。
堆栈污染可能是缓冲区溢出的结果。如果在局部变量数组上使用 memcpy 或集合循环并超出数组末尾，则可以破坏堆栈。
You can make some information from the ARM thread state. The PC register is the only one containing the invalid address that the crash report is complaining about. That means your app tried to execute code at that address.
SIGSEGV means that the address in question is invalid. The system has setup no memory pages with this address.
I don't think the iOS will allow you to simply execute code from any address, but it is possible that the stack frame was corrupted and the return address was invalid when a function returned. That supports the "backtrace not available" problem.
Fouling the stack may be a result of a buffer overrun. If you use memcpy or a loop of sets on a local variable array and overrun the end of the array, you can destroy the stack.