Biu~笔记：高通蓝牙ADK（41）-- 死机分析

Bui~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

啊ε＝ε＝ε＝(#>д<)ﾉ  死机！！！crash！！跑飞！！！  

╮(╯▽╰)╭ 一点都不可怕

 

如果是软件造成的死机都是可以寻迹的，高通也提供了方便的途径去查询死机的问题。例如当死机发生后，连接上QMDE进行调试。查看死机所在的函数。用pydbg输入指令apps1.stack()就可以看到在哪个函数里面死机了，这个功能也就是QMDE里面的callstack窗口。但这个方法一般用在参数有问题造成的死机 ，对应内存溢出这种就莫得办法。对于这种情况，就需要用到内存分析指令，在pydbg输入指令apps1.fw.pmalloc.info()查询当前memory 分配的状态信息；用apps1.fw.pmalloc.report()查看哪些函数申请了空间。也可以通过apps1.fw.gbl.<var_name>查看一下全局变量是不是参数正常。如果遇到死机时，没办法及时debug或想给别人debug，那我们可以先把coredump获取到。但是不管什么方法，debug死机问题我们都需要设置一下，让软件在死机的时候不要重启和不要忽视，要在那里等我们去抓。

• 对于ADK6.x：

           在subsys0_config3.htf文件里面添加下面两个key：

           ResetOnAppPanicOrWatchdog = false

           HaltAllSubsystemsOnPanic = true

• 对于后面新的ADK：

           在subsys0_config2.htf文件里面修改下面一个key：

           PanicAction=2

当死机之后，获取coredump的操作也简单，新旧adk大同小异

• 对于ADK6.x：

           通过QMDE->Tools->Obtain coredump

• 对于后面新的ADK：

通过QMDE->Tools-> CoreDump(这里面有获取单个和多个的选项，根据需求自行选择)

另外，这个有些ADK支持离线存储的功能，详情可看Biu~笔记：高通蓝牙ADK（12）--离线log - 大大通(简体站) (wpgdadatong.com.cn)

• 对于想让你的客户去抓取，客户又不想装软件的，你可以教他用toolkit里面的指令去抓（但是不建议自己去这样抓，因为还需要自己去收集elf文件）：
• 

QMDE抓完之后，会在下面的提示框输出文件路径，大概是adk-src-1-0_qtil_standard_oem_qcc518x-qcc308x\headset\workspace\QCC3084-AA_DEV-BRD-R3-AA_LEA\coredump 这样子的路径。

有了coredump文件之后，我们就可以进行分析了。这里要用到QMDE里的加载功能，

• Tools-> Load coredump into pydbg（ADK6.x）
• Tools-> CoreDump->Load coredump into pydbg（新ADK）

加载时，按照提示选择对应的elf文件即可，完成之后，就可以在pydbg窗口输指令查看消息了。

 

以上是本期博文的全部内容，如有疑问就别在博文下方评论留言了，有什么疑问或想了解的当面和我说（如果你知道我是谁的话ヽ(￣▽￣)و），我会尽量安排上(o´ω`o)و。谢谢大家浏览，我们下期再见。

简单是长期努力的结果，而不是起点

                                                 —— 不是我说的

FAQ 1：如果是非软件造成的死机呢？

A1：→_→求神拜佛吧，这种情况一般千奇百怪，概率又小，只能一步步去测试分析

 

FAQ 2：离线log功能，能放多少次死机的log

A2：理论上只要你分配的空间足够多，可以放很多很多很多很多

 

FAQ 3：DSP死机是怎么样的？

A3：应用层一般是正常跑，但是输出的声音会是静音或持续噪音

 

FAQ 4：DSP死机怎么分析？

A4: 这部分一般自己分析不好分析，交给专业的人吧(→ ω →)

 

FAQ 5：死机可以用usb debug吗？

A5: 可以