通过崩溃trace来查找问题原因

从友盟中, 我们可能会得到如下信息:

Application received signal SIGSEGV

(null)
(
	0   CoreFoundation                      0x359348a7 __exceptionPreprocess + 186
	1   libobjc.A.dylib                     0x37cdb259 objc_exception_throw + 32
	2   CoreFoundation                      0x35934789 +[NSException raise:format:] + 0
	3   CoreFoundation                      0x359347ab +[NSException raise:format:] + 34
	4   NxxMovie                          0x1153b9 _mh_execute_header + 1131449
	5   libsystem_c.dylib                   0x32d407e3 _sigtramp + 38
	6   NxxMovie                          0x390fb _mh_execute_header + 229627
	7   CoreFoundation                      0x358931fb -[NSObject performSelector:withObject:] + 42
	8   NxxMovie                          0x175a5 _mh_execute_header + 91557
	9   CoreFoundation                      0x358931fb -[NSObject performSelector:withObject:] + 42
	10  Foundation                          0x35457747 __NSThreadPerformPerform + 350
	11  CoreFoundation                      0x35908ad3 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 14
	12  CoreFoundation                      0x3590829f __CFRunLoopDoSources0 + 214
	13  CoreFoundation                      0x35907045 __CFRunLoopRun + 652
	14  CoreFoundation                      0x3588a4a5 CFRunLoopRunSpecific + 300
	15  CoreFoundation                      0x3588a36d CFRunLoopRunInMode + 104
	16  GraphicsServices                    0x37526439 GSEventRunModal + 136
	17  UIKit                               0x33396cd5 UIApplicationMain + 1080
	18  NxxMovie                          0x31b7 _mh_execute_header + 8631
	19  NxxMovie                          0x3150 _mh_execute_header + 8528
)

dSYM UUID: FF67F6D3-C71C-3A7D-9C4C-C4FFBF8EEEB9
CPU Type: armv7
Slide Address: 0x00001000
Binary Image: NxxMovie
Base Address: 0x000f4000

由于这类的崩溃信息通常难以重现, 没有任何的重现步骤,所以我们得找到发布该版本时的原始代码,可能会需要回朔到以前的SVN或者Git版本。

然后找到当时上传代码时使用的DYSM文件,这文件通常在.xcarchive文件中。 右键该文件, 然后通过Terminal工具cd到

cd /Users/heqin/Downloads/xxxMovie2.0.0_apps_0605_2104\ 13-6-5\ 下午9.02.xcarchive/dSYMs/xxxMovie.app.dSYM/Contents/Resources/DWARF

注意:1。对于成功生成archvie的项目, 在这个archive的包中, 是可以通过显示包内容, 看到DSYMs文件夹和一个products文件夹, 继续显示DSYMs文件夹下,可以看到一个xxx.app.DSYM文件,继续对它显示包内容,可以看到Contents/Resources/DWARF/xxxx文件, 这个文件是编译后的二进制文件,通过它可以进行反编译,从而找到二进制对应的源码位置。

2。 在xcode中,archive成功后, 会在Organizer界面中的Archives下, 可以看到所有的archive文件, 右键Show in Finder可以找到这个文件。

然后执行atos -arch armv7 -o xxxMovie 0x1153b9. 就可以看到这处内存地址反编译回来的源码行。

可以有效地帮助分析原因。

通过崩溃trace来查找问题原因

时间: 2024-08-05 08:47:00

通过崩溃trace来查找问题原因的相关文章

让Web站点崩溃最常见的七大原因

磁盘已满 导致系统无法正常运行的最可能的原因是磁盘已满.一个好的网络管理员会密切关注磁盘的使用情况,隔一定的时间,就需要将磁盘上的一些负载转存到备份存储介质中(例如磁带).日志文件会很快用光所有的磁盘空间.Web服务器的日志文件.SQL*Net的日志文件.JDBC日志文件,以及应用程序服务器日志文件均与内存泄漏有同等的危害.可以采取措施将日志文件保存在与操作系统不同的文件系统中.日志文件系统空间已满时Web服务器也会被挂起,但机器自身被挂起的几率已大大减低. C指针错误 用C或C++编写的程序,

让 Web 站点崩溃最常见的七大原因

磁盘已满 导致系统无法正常运行的最可能的原因是磁盘已满.一个好的网络管理员会密切关注磁盘的使用情况,隔一定的时间,就需要将磁盘上的一些负载转存到备份存储介质中(例如磁带).   日志文件会很快用光所有的磁盘空间.Web服务器的日志文件.SQL*Net的日志文件.JDBC日志文件,以及应用程序服务器日志文件均与内存泄漏有同等的危害.可以采取措施将日志文件保存在与操作系统不同的文件系统中.日志文件系统空间已满时Web服务器也会被挂起,但机器自身被挂起的几率已大大减低. C指针错误 用C或C++编写的

利用Trace file查找程序发出的SQL

Trace file(追踪文件)是以trc为后续的文本文件,它记录了各种sql操作及所消耗的时 间等,根据trace文件我们就可以了解哪些sql导致了系统的性能瓶颈,进而采取恰当的 方式调优. 查询生产报表—所有制程的WIP: show parameter sql_trace; (如果value是false表示系统当前不会产生trace文件.采取如下操作让系统产生trace 文件.) alter session set sql_trace=true; EXEC DBMS_MONITOR.DATA

在崩溃转储中查找所有可能的上下文记录

如果您调试了一段时间的崩溃转储,那么您可能遇到了这样的情况:调试器提供的初始转储上下文对应于在处理初始异常时发生的第二个异常,该异常可能更接近您正在调查的问题中的原始基础问题.这可能很烦人,因为“.ecxr”命令将指向次要故障异常的位置,而不是原始异常上下文本身.然而,在大多数情况下,原始的.主要的异常上下文仍然在堆栈上:人们只需要知道如何找到它. 有两种方法可以解决这个问题: 对于硬件生成的异常(access violations),可以查找堆栈上的ntdll!KiUserExceptionD

网站导致浏览器崩溃的原因总结(多款浏览器)

面试某公司的时候,面试官问到,导致浏览器崩溃的原因有哪些?愚辈不才,仅回答出了内存泄漏.其实在网页在装载的过程中,常常由于种种原因使浏览器的反映变的很慢,或造成浏览器失去响应,甚至会导致机器无法进行其他的操作. 对于访客,如果登录您网站,浏览器就立刻崩溃,我想这对谁都是无法容忍的,对此总结了网站导致浏览器崩溃的原因: 1. 内存泄漏 还是先谈下内存泄漏,网站由于内存泄漏的而照成崩溃有两种情况,服务器的崩溃和浏览器的崩溃.内存泄漏所造成的问题是显而易见的,它使得已分配的内存的引用就会丢失,只要系统

iOS应用崩溃日志分析

转自raywenderlich 作为一名应用开发者,你是否有过如下经历? 为确保你的应用正确无误,在将其提交到应用商店之前,你必定进行了大量的测试工作.它在你的设备上也运行得很好,但是,上了应用商店后,还是有用户抱怨会闪退 ! 如果你跟我一样是个完美主义者,你肯定想将应用做到尽善尽美.于是你打开代码准备修复闪退的问题……但是,从何处着手呢? 这时iOS崩溃日志派上用场了.在大多数情况下,你能从中了解到关于闪退的详尽.有用的信息. 通过本教程,你将学习到一些常见的崩溃日志案例,以及如何从开发设备和

iOS 应用崩溃日志分析

通过本教程,你将学习到一些常见的崩溃日志案例,以及如何从开发设备和iTunes Connect上获取崩溃日志文件.你还将学习到符号化( symbolication),从日志追踪到代码 .你还将学习调试一个在待定情况下会闪退的应用. 让我们开始动手吧! 什么是崩溃日志,从哪里能得它? iOS设备上的应用闪退时,操作系统会生成一个崩溃报告,也叫崩溃日志,保存在设备上. 崩溃日志上有很多有用的信息,包括应用是什么情况下闪退的.通常,上面有每个正在执行线程的完整堆栈跟踪信息,所以你能从中了解到闪退发生时

iOS应用崩溃日志分析-备用

作为一名应用开发者,你是否有过如下经历? 为确保你的应用正确无误,在将其提交到应用商店之前,你必定进行了大量的测试工作.它在你的设备上也运行得很好,但是,上了应用商店后,还是有用户抱怨会闪退 ! 如果你跟我一样是个完美主义者,你肯定想将应用做到尽善尽美.于是你打开代码准备修复闪退的问题……但是,从何处着手呢? 这时iOS崩溃日志派上用场了.在大多数情况下,你能从中了解到关于闪退的详尽.有用的信息. 通过本教程,你将学习到一些常见的崩溃日志案例,以及如何从开发设备和iTunes Connect上获

崩溃日志的查看

作为一名应用开发者,你是否有过如下经历? 为确保你的应用正确无误,在将其提交到应用商店之前,你必定进行了大量的测试工作.它在你的设备上也运行得很好,但是,上了应用商店后,还是有用户抱怨会闪退 ! 如果你跟我一样是个完美主义者,你肯定想将应用做到尽善尽美.于是你打开代码准备修复闪退的问题……但是,从何处着手呢? 这时iOS崩溃日志派上用场了.在大多数情况下,你能从中了解到关于闪退的详尽.有用的信息. 通过本教程,你将学习到一些常见的崩溃日志案例,以及如何从开发设备和iTunes Connect上获