美文网首页
iOS崩溃日志分析入门

iOS崩溃日志分析入门

作者: 落叶情思 | 来源:发表于2021-03-04 15:53 被阅读0次

    怎么获取崩溃日志

    获取日志的N+1中方式

    常见crash格式

    通常来说,iOS崩溃之后从系统导出的崩溃文件一般是以ips为后缀的,其实就是正常的文字格式,后缀是可以随意改的

    Crash的基本信息

    image
    Incident Identifier: crashlog 文件唯一标识符,类似于苹果设备的 udid。
    Hardware Model: 标识硬件设备类型,如果有许多崩溃日志该字段相同,那么有可能是某种特定机型的问题
    Process: 发生崩溃的进程名称和对应的 processID。
    Path: 发生崩溃应用的文件路径。
    Indentify、 version、 Code Type: 发生崩溃应用的 bundleID、版本、编码类型。
    Role:发生崩溃时应用是在前台还是后台,这是一个复现和分析 crash 的重要信息。 有些问题是在应用退到后台时才会发生, 比如百度导航压力测试时,如果该字段为
    backforeground:可以猜想是否是长时间后台导航导致 crash。
    Date/Time:发生崩溃的具体时间。
    Launch/Time: 应用开始运行的时间。如果想要知道应用在运行多久后发生了崩溃, 可以用 Launch/Time- Date/Time
    OS Version: 操作系统版本,与 Hardware Model 字段类似,如果有许多崩溃日志该字段相同,那么有可能是某种系统的问题。

    异常信息

    image
    异常信息包括异常类型(exception type)、异常子类型(exception subtype)、异常编码(exception code)、 异常描述(exception note)异常线程号(Triggered by Thread)和其它异常信息,crashlog 文件会给出以上几种或者全部异常字段。
    • 异常类型

    异常类型对应的字段是 Exception type, 一般包含两个元素: Mach 异常+Unix 信号(括号中的内容), Mach 是 XNC 内核核心, Mach 异常是内核级异常, Mach 异常在 host 层被ux_exception 转换为响应的 Unix 信号,并通过 thread signal 将信号投递至出错的线程。

    Crashlog 中常见的 Mach 异常有以下几种:

    • EXC_BAD_EXCESS: 该类异常通常是由于访问了不该访问的内存导致。
    • EXC_CRASH: app 进行了系统不支持的操作。
    • EXC_BAD_INSTRUCTION: 执行非法指令。
    • EXC_ARITHMETIC: 计算异常,比如除零操作。
    • EXC_RESOURCE: 该种异常并非一个真正的 crash,而是系统告诫进程正在使用的资源过多。 如果 subtype 类型为 wakeup, 就表示某个线程被唤醒次数过多。如果 subtype 类型为 memory, 就表示超过了系统内存限制,可能会导致系统强制 Kill 进程。
    • EXC_GUARD: 进程侵犯了被保护的资源。
    • EXC_BREAKPOINT:断点调试时异常退出。

    Crashlog 中常见的 Unix 信号有以下几种:

    • SIGSEGV: 访问了未分配的内存或者往没有写权限的内存地址中写数据,比如重复释放对象, 多线程操作同一个对象。
    • SIGABRT: 收到了 abort 信号中止进程,比如调用了未实现的方法或者数组越界。
    • SIGBUS:总线访问错误,访问地址有效,但是地址未对齐等。
    • SEGILL: 执行了非法指令。
    • SEGKILL:立即结束进程运行的信号,比如内存不足被 Kill 掉。
    • SEGTRAP:由断点指令或者其他 trap 指令产生。
    • SEGFPE:浮点异常

    Unix 信号还有很多,此处仅列举 Crashlog 文件中常见的信号类型。

    1. 异常编码
      异常类型对应的字段是 exception code,通过异常编码可以大致确认 crash 引发的原因,常见的异常编码有一下几种。
    • 0x8badf00d:程序被 watchdog 终止掉,比如程序启动或者恢复超时。
    • 0xbad2222:指 VoIP 应用(后台网络)在后台过于频繁的被激活。
    • 0xbaaaaaad: 代表该 crash 并非一个真正的 crash,仅仅保存了应用某一个时刻的运行状态。
    • 0xdeadfa11:程序无响应,用户强制 Kill。
    • 0xc00010ff:程序执行大量耗费 CPU 和 GPU 运算,导致设备过热,被系统中止。
    • 0xdead10cc:程序退至后台,仍然占用着系统资源。

    线程回溯信息

    异常信息后面显示的是线程回溯信息,记录了发生崩溃时每个线程的调用堆栈,是crashlog 文件的主体,后面会重点介绍。


    image

    线程状态

    该部分保存发生 crash 时寄存器中的值。


    image

    重点关注

    • 1.对于包含有Last Exception Backtrace:我们要重点关注Last Exception Backtrace:的线程,因为这个线程是苹果或者我们的程序员主动抛出的异常信息,堆栈里会有抛出异常时详细的堆栈信息

      image
    • 2.对于不包含有Last Exception Backtrace:,我们就需要重点关注Crashed线程以及异常类型的信息,这种崩溃,通常都是底层抛出的signal触发分崩溃,关注Crashed线程更能解决问题。

      image

    二进制映像

    该部分列出了发生 crash 之前已经成功加载的二进制文件。


    image

    其它类型 crashlog 文件

    除了常见的 crashlog 文件外,还有其它不同结构的 crashlog 文件,比如低内存、 CPUUsage 等。低内存 crashlog 的 process 名称和 type 一般为 unknown, 文件结构中没有线程回溯信息, 如下所示。

    • ① 基本信息,包括识别号、 操作系统版本等。
    • ② 内存分配信息和当前占用内存最多的进程。
    • ③ 每个进程所使用的内存信息,包括所使用的内存页数、当前状态等。


      image

      低内存崩溃无法从 crashlog 中获取有效的定位信息,可进一步分析进程内存分配方式,或者使用 instruments 的 Allocation 和 Leak 工具来发现问题。

    崩溃日志解析(静请期待下期讲解)

    参考资料

    相关文章

      网友评论

          本文标题:iOS崩溃日志分析入门

          本文链接:https://www.haomeiwen.com/subject/tiskqltx.html