【发布时间】:2012-08-20 05:23:43
【问题描述】:
我无法理解我的崩溃日志。我可以理解它在第 9 个线程上崩溃。所以看看我的第 9 个线程
Thread 9 Crashed:
0 libobjc.A.dylib 0x30da4f78 objc_msgSend + 16
1 APLfree 0x0009be1c 0x1000 + 634396
2 Foundation 0x30514a7a -[NSThread main]
3 Foundation 0x305a858a __NSThread__main__
4 libsystem_c.dylib 0x3763872e _pthread_start
5 libsystem_c.dylib 0x376385e8 thread_start
这是否意味着 libsystem_c.dylib 导致了崩溃或可能是 libobjc.A.dylib?
我自己没有遇到崩溃,但我是从我的应用程序的真实用户的崩溃日志中获得的。它至少出现在 iOS 5.1、5.0、4.3 和 4.2.6 中。所以这不是最新 iOS 中的新错误。
我怀疑这可能是释放内存的问题,但我不太擅长追踪这些问题,所以如果有任何关于如何修复内存泄漏等的建议也会有所帮助。
任何帮助将不胜感激!
谢谢,
特拉维斯
【问题讨论】:
-
通常你从上到下阅读堆栈跟踪。这意味着 libsystem_c.dylib 导致了崩溃,但不是真的,你导致了崩溃,可能是通过传递一个无效的指针或在你不应该的时候释放它。我不是阅读 iOS 代码的专家,但我敢打赌,这份堆栈报告并不能真正告诉你太多。也许您应该考虑使用动态检测工具来追踪泄漏(看起来 valgrind 可以与 iOS 模拟器一起使用..)
-
我同意@KristopherMicinski 的观点。另一种方法可能是插入断点并找到导致崩溃的地方
-
您能否在自己的设备上重现崩溃?如果是这样,您可以在调试器运行的情况下执行此操作,并准确查看导致问题的代码行,或者当时正在释放的对象。您也可以尝试在启用
NSZombies的情况下运行,以查看您是否正在双重释放某些内容,或者释放未分配的内容。 -
您好,感谢您的建议。问题是我自己没有崩溃。也许这是一个间歇性问题,或者也许只有旧设备会崩溃而我的不会。很难说。如果我自己能轻松复制它,我就能找到它。
-
它不太可能与旧设备有关。通常,此类问题要么针对应用程序的特定使用顺序发生,要么在长时间使用后发生。在任何一种情况下,使用UIAutomation 或KIF 创建用户交互测试用例,以不同的顺序运行您的应用程序并运行更长的时间。这很可能会以可重现的方式揭示错误。
标签: ios memory crash report memory-leaks