zoukankan      html  css  js  c++  java
  • iOS 崩溃日志 Backtrace的符号化

    iOS的崩溃日志配合dsym文件可以找到崩溃时的backtrace,这是解决崩溃的最重要的信息.

    如果是在同一台mac上打包, 导入crash log时候会自动将backtrace符号化,可以看到方法名, 文件名和行号

    但是,有时候发版的包不是在你的mac上打包的,xcode找不到对应的符号表, backtrace没能符号化如下所示:

    Last Exception Backtrace:
    0 CoreFoundation 0x2cb535f2 __exceptionPreprocess + 122
    1 libobjc.A.dylib 0x3a3c5c72 objc_exception_throw + 34
    2 CoreFoundation 0x2ca67152 -[__NSArrayM objectAtIndex:] + 226
    3 myapp 0x004fe736 0x9b000 + 4601654
    4 myapp 0x00507ed4 0x9b000 + 4640468
    5 myapp 0x004fd112 0x9b000 + 4595986
    6 myapp 0x003275c6 0x9b000 + 2672070

    这里第二行可以看到是一个数组objectAtIndex抛出异常,但是3-6行的是来自应用自己的代码myapp, 这些信息才是最重要的.

    其实,只要有原app文件,是可以将这些信息找到.

    方法:

    将对应版本的myapp.app文件和crash文件放在同一个文件夹下, 注意,一定要是该应用正确版本的app, 因为每次打包, 符号表的映射关系都有可能不同,如果不对应的话是没法符号化的.

    然后运行

    atos -arch armv7 -o myapp.app/myapp -l 0x9b000 0x004fe736

    这个方法 -arch后面是指硬件架构:
    iphone 1,2,3 是armv6
    iphone4,4s 是 armv7
    iphone5,5c是armv7s
    iphone 5s, 6, 6+, 6s, 6s+ 是arm64

    根据崩溃发生的设备来选择上述架构, myapp.app就是你的app的文件名, 选项l后面的两个16进制数是关键:
    第一个数字,取backtrace的要解析的行的第4列, 第二个数字取第3列, 就会得到对应的方法名,文件名,行号.
    这样,可以将上述3-6行中一行一行的解析出来,就能看到发生崩溃的地方,再进行分析就简单了.

  • 相关阅读:
    访问修饰符
    SqlServer 查运行进程
    SqlServer 作业计时执行存储过程,杀超时进程
    VS快捷键操作
    sql server 命令
    vs 加载 dev控件
    TreeList显示[+] [-] 线条样式
    佳能MG2580S清零
    Dev WaitDialog 使用
    导出.txt / .pdf / .xls
  • 原文地址:https://www.cnblogs.com/dqshll/p/5142013.html
Copyright © 2011-2022 走看看