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: 可以