2. 程式人生 > 其它 >HaaS100開發除錯系列 之 使用AliOS Things診斷除錯元件定位Bug

HaaS100開發除錯系列 之 使用AliOS Things診斷除錯元件定位Bug

阿新 • • 發佈：2021-01-04

技術標籤：AliOS Things物聯網作業系統嵌入式實時作業系統debugger物聯網HaaS

1、背景

在嵌入式開發中，我們經常遇到的一個問題是：寫程式碼一個不小心，就製造了一個bug，C語言中bug的威力大家也心知肚明——可以直接把系統搞掛！

即大家常見的系統宕機、系統重啟等等；而問題的來源或者根因，又常常使得我們束手無策，只好採用“列印”大法，一遍遍的加printf。

而每次改程式碼又要經歷痛苦的“編譯-燒寫-執行-復現”這個過程，不知不覺，一天過去了，bug還沒解。

所以我們經常想，要是系統能直接告訴我們bug在哪、是什麼錯誤導致的就好了，直接改程式碼分分鐘搞定，可以節省很多開發時間！

這也是我們常用一些模擬器（如JLINK）的原因，系統掛死後可以掛上模擬器，檢視PC在哪，通過bt檢視呼叫棧等來幫助我們定位。

而這又對硬體有了一定的要求——要能支援模擬器連線，有時還要開發者折騰一下環境。

我們的HaaS100雖然也支援硬體連線模擬器（參考上一篇帖子：HaaS100開發除錯系列 之 如何使用J-Link模擬器除錯程式碼）。

這裡我們告知大家一個更方便定位系統異常宕機的方法——AliOS Things的診斷除錯元件。

2、診斷除錯元件簡介

診斷除錯包含的內容很多，前面我們介紹過一些除錯命令，參見文章《一文輕鬆入門HaaS100診斷除錯系統》。

本文我們重點介紹的是AliOS Things的診斷除錯元件是怎麼幫助解決程式碼bug

的。

診斷除錯元件可以縮短bug定位時間。

如果一個bug出現導致系統異常後，使用者可以不用連模擬器、不用加列印、不用開啟gdb單步除錯的情況下，可以快速找到bug原因。

或者幫助使用者指出可能的異常點，進而修復以節省開發時間。

舉例說明：

  • 程式碼中訪問了非法記憶體（比如：在不可寫的地址處寫了資料，如訪問了0地址）導致系統奔潰，AliOS Things診斷除錯元件可以記錄訪問非法記憶體時的pc值，告訴使用者掛在了哪一行；
  • 程式碼跑飛了(pc=0)，AliOS Things診斷除錯元件記錄了函式呼叫的棧，並根據棧向上回溯可以找到A->B->C的函式呼叫過程，與模擬器中bt命令類似；
  • 使用者記憶體申請時malloc 失敗，AliOS Things診斷除錯元件可以記錄使用者此時申請了多少記憶體、此時系統還有多少記憶體可以供申請、使用者是在哪個任務中申請的記憶體、從系統啟動開始記憶體的申請情況等資訊，這些資訊可以幫助開發者定位是否有記憶體洩漏的情況。
  • ......

AliOS Things的診斷除錯元件可以幹很多事，後面我們會陸續推出文章來介紹。

今天我們只看一個問題——bug產生了，系統異常掛死了，那麼AliOS Things會做哪些事呢?

簡單一句話回答，輸出重要的log幫助大家定位問題，這也是AliOS Things的診斷除錯元件最重要的部分。

3、AliOS Things的異常log到底是啥樣

直接上HaaS100輸出的log

!!!!!!!!!! Exception  !!!!!!!!!!
========== Regs info  ==========  異常現場暫存器資訊
R0      0x00000000
R1      0x34027F20
R2      0x34027F30
R3      0x340251B4
R4      0xFFFFFFFF
R5      0x00000000
R6      0x2C0D2C72
R7      0x00000001
R8      0x2C0D2C86
R9      0x2C0D236B
R10     0x00000000
R11     0x00000000
R12     0x0000C000
LR      0x1C5D6CC3
PC      0x1C5D6CC2
xPSR    0x61000000
SP      0x34025118
EXC_RET 0xFFFFFFBC
EXC_NUM 0x00000006
PRIMASK 0x00000000
FLTMASK 0x00000000
BASEPRI 0x00000000
CFSR    0x01000000
HFSR    0x00000000
MMFAR   0xE000ED34
BFAR    0xE000ED38
AFSR    0x00000000
========== Stack info ==========  異常現場棧資訊
stack(0x34025118): 0x34027D20 0x340251B4 0x00000000 0x34022F98 
stack(0x34025128): 0x00000000 0x34682380 0x1C5D6BBD 0x00000005 
stack(0x34025138): 0x00000006 0x1C5D621F 0x00000003 0x2C0D2A0C 
stack(0x34025148): 0x340230C4 0x00000013 0x34682280 0x00000000 
stack(0x34025158): 0x000000F7 0x00000005 0x00000003 0x00000000 
stack(0x34025168): 0x00000000 0x00000000 0x00000001 0x34682380 
stack(0x34025178): 0x34022F98 0x0000000B 0x34022FA8 0x00000000 
stack(0x34025188): 0x000000F6 0x00000001 0x2C0D294D 0x1C5D63D3 
stack(0x34025198): 0x00000000 0x2C0D1BD0 0x00000000 0x0D000000 
stack(0x340251A8): 0x78300070 0x66666666 0x66666666 0x00003100 
stack(0x340251B8): 0x00000000 0x00000000 0x00000000 0x00000000 
stack(0x340251C8): 0x00000000 0x00000000 0x00000000 0x00000000 
stack(0x340251D8): 0x00000000 0x00000000 0x00000000 0x00000000 
stack(0x340251E8): 0x00000000 0x00000000 0x00000000 0x00000000 
stack(0x340251F8): 0x00000000 0x00000000 0x00000000 0x00000000 
stack(0x34025208): 0x00000000 0x00000000 0x00000000 0x00000000 
========== Call stack ==========  棧回溯資訊，可以得出函式呼叫過程
backtrace : 0x1C5D6CC2 
backtrace : 0x1C5D621C 
backtrace : 0x1C5D63CE 
backtrace : ^task entry^
========== Heap Info  ==========  系統此時的記憶體資訊，可以看出記憶體申請了多少，還剩多少
---------------------------------------------------------------------------
[HEAP]| TotalSz    | FreeSz     | UsedSz     | MinFreeSz  | MaxFreeBlkSz  |
      | 0x00680000 | 0x0065A300 | 0x00025D00 | 0x00659E20 | 0x0065A300    |
---------------------------------------------------------------------------
========== Task Info  ==========   系統當前任務狀態資訊，可以看出任務棧是否過小
--------------------------------------------------------------------------
TaskName             State    Prio       Stack      StackSize (MinFree)
--------------------------------------------------------------------------
dyn_mem_proc_task    PEND     0x00000006 0x2004B938 0x00000400(0x0000035C)
idle_task            RDY      0x0000003D 0x2004BE0C 0x00001000(0x00000F94)
DEFAULT-WORKQUEUE    PEND     0x00000014 0x2004F1E8 0x00000C00(0x00000B7C)
timer_task           PEND     0x00000005 0x2004D0D8 0x00002000(0x00001F48)
main                 SLP      0x00000021 0x2015A000 0x00005000(0x000044C4)
transq_msg           PEND     0x0000001F 0x3469A4C4 0x00001000(0x00000680)
apps_recover         SLP      0x00000021 0x2004A588 0x00001000(0x00000F64)
temp_main            SLP      0x00000021 0x346A15D8 0x00001000(0x00000F80)
main_task            SLP      0x00000020 0x34002668 0x00020000(0x0001F6C4)
cli                  RDY      0x0000003C 0x340232D0 0x00002000(0x0000180C)
ulog                 PEND     0x0000003C 0x34026890 0x00000C00(0x00000A58)
========== Queue Info ==========   AliOS Things kernel queue使用資訊
-------------------------------------------------------
QueAddr    TotalSize  PeakNum    CurrNum    TaskWaiting
-------------------------------------------------------

======== Buf Queue Info ========  AliOS Things kernel buf queue使用資訊
------------------------------------------------------------------
BufQueAddr TotalSize  PeakNum    CurrNum    MinFreeSz  TaskWaiting
------------------------------------------------------------------
0x2004FDE8 0x000001E0 0x00000000 0x00000000 0x000001E0 timer_task          
0x34025420 0x00001400 0x00000000 0x00000000 0x00001400 ulog

=========== Sem Info ===========  AliOS Things kernel semphore使用資訊
--------------------------------------------
SemAddr    Count      PeakCount  TaskWaiting
--------------------------------------------
0x2004CF60 0x00000000 0x00000000 dyn_mem_proc_task   
0x2004F1B8 0x00000000 0x00000000 DEFAULT-WORKQUEUE   
0x340023A0 0x00000001 0x00000001                     
0x34002478 0x00000000 0x00000000                     
0x340025D0 0x00000001 0x00000001                     
0x34682C34 0x00000000 0x00000000                     
0x34682C58 0x00000000 0x00000000                     
0x340275B0 0x00000000 0x00000000                     
!!!!!!!!!! dump end   !!!!!!!!!!

3.1、Log分析

上面的log是在HaaS100上產生系統異常後，由AliOS Things輸出的log。log可以分為：

  • 異常現場暫存器：跟arch相關的通用暫存器和一些特殊暫存器資訊；
  • 異常棧資訊：產生異常的任務的棧資訊；
  • 棧回溯資訊：產生異常的呼叫棧，類似模擬器中的bt命令，這個是異常log中最重要的部分；
  • 記憶體資訊：系統此時的記憶體狀態，對於定位一些記憶體洩漏問題比較有用；
  • 任務資訊：系統當前的任務狀態資訊，對於定位任務棧溢位問題比較有用；
  • 核心資訊：包含了kernel 中的queue、buf_queue 和 sem狀態。

log中所示的記憶體包含了很多核心相關的內容，後續我們也會推出文章來介紹AliOS Things的核心。

3.2、如何開啟診斷除錯元件

使用者只需要在aos.mk裡包含debug元件，重新編譯燒錄上電即可。

$(NAME)_COMPONENTS += debug

3.3、如何產生一個系統異常

理論上任何一個系統異常後，都會出現類似上面的log，如果開發者對產生系統異常感興趣，可以使用下面的簡單方法：

m 0xffffffff 1

即使用系統提供的cli 命令，改寫系統位於0xfffffff出的記憶體值為1，地址0xfffffff在HaaS100上為不可寫的區域，改寫這個值可以觸發系統異常，打印出上面的log。

使用cli命令的方法可以參考另外一篇文章《一文輕鬆入門HaaS100診斷除錯系統》

3.4、呼叫棧的價值

呼叫棧的資訊輸出是AliOS Things診斷除錯元件的核心，我們通過上面的命令產生異常後，使用toolchain自帶的arm-none-eabi-addr2line 命令對上面log中的call stack呼叫棧中的地址進行解析，使用方法是：

 arm-none-eabi-addr2line -pfiCe xxx.elf addr

以log中輸出的call stack地址為例：

./build/compiler/gcc-arm-none-eabi/Linux64/bin/arm-none-eabi-addr2line -pfiCe out/[email protected]/binary/[email protected] 0x1C5D6CC2 0x1C5D621C 0x1C5D63CE

可以解析出呼叫棧所對應的程式碼位置，如：

pmem_cmd at /workspace/hass/AliOS-Things/core/cli/cli_default_command.c:224

proc_onecmd at /workspace/hass/AliOS-Things/core/cli/cli.c:173
 (inlined by) cli_handle_input at /workspace/hass/AliOS-Things/core/cli/cli.c:290

cli_main at /workspace/hass/AliOS-Things/core/cli/cli.c:781

我們可以清楚看到發生異常的函式呼叫過程，並且指出了函式程式碼的路徑和行號。

cli_main  -- >  proc_onecmd ---> pmem_cmd

4、筆者的話

大家有沒有覺得，通過這個方法定位Bug，讓異常發生的位置一目瞭然，我們快速找到這行程式碼後修改，分分鐘解決了這個Bug。又可以開心的繼續幹活了！

不過，AliOS Things診斷除錯元件只是儘可能的幫助大家節省解Bug的時間，而有些Bug的產生並不會導致系統異常，但會給系統埋下不穩定的伏筆，這個時候再好的診斷工具也沒用了。

大家還是要多修煉寫程式碼內功，不產生bug才是我們的追求！

5、開發者技術支援

如需更多技術支援，可加入釘釘開發者群

更多技術與解決方案介紹，請訪問阿里雲AIoT首頁https://iot.aliyun.com/

相關推薦

HaaS100開發除錯系列 之 使用AliOS Things診斷除錯元件定位Bug

技術標籤：AliOS Things物聯網作業系統嵌入式實時作業系統debugger物聯網HaaS 1、背景

鴻蒙開發實戰系列之四：資料庫NoSQL-ObjectBox的使用

技術標籤：鴻蒙javaandroid移動開發 鴻蒙開發實戰系列之一：鴻蒙開發實戰系列之一：圓角

Java技術開發專題系列之【Guava RateLimiter】針對於限流器的入門到精通（針對於原始碼分析介紹）

Guava包中限流實現分析 RateLimiter 之前的文章中已經介紹了常用的限流演算法，而google在Java領域中使用Guava包中的限流工具進行服務限流。

新閣上位機開發--資料庫系列之特定例項錯誤

前言         對於出現上位機開發的同學來說，大家在學習資料庫的時候，以上兩個錯誤基本上是不可避免的，圖1是使用SSMS登入時出現的錯誤，圖2是通過C#程式碼連線資料庫時出現的錯誤。

鴻蒙HarmonyOS App開發造輪子之自定義圓形圖片元件的例項程式碼

一、背景 在採用Java配合xml佈局編寫鴻蒙app頁面的時候，發現sdk自帶的Image元件並不能將圖片設定成圓形，反覆了翻閱了官方API手冊（主要查閱了Compont和Image相關的API），起初發現了一個setCornerRadius方法，於是

SpringBoot系列之傳送郵件開發手冊

@目錄一、Email前言介紹二、Email例子實踐2.1 開發實驗環境準備2.2 Meavn配置檔案2.3 application配置2.4 傳送文字格式郵件2.5 傳送Html格式郵件2.6 傳送html內嵌圖片2.7 傳送模板html郵件2.8 傳送Attachment郵件

微信開發系列之七 - 使用Redis儲存微信聊天記錄

In the second blog Wechat development series 2 – development Q&A service using nodejs of this series, we have developed a kind of Q&A service in Wechat which leverages a free Tuning Restful s

上雲安全，有我守護。初觀HaaS100中AliOS Things系統安全能力

技術標籤：AliOS Things物聯網作業系統嵌入式iotrtos安全作業系統 1、智慧裝置安全考慮

go語言web開發系列之五:gin用zap+file-rotatelogs實現日誌記錄及按日期切分日誌

技術標籤：用go做web開發gogolangwebapilog4j2 一，安裝需要用到的庫: 1，安裝zap日誌庫:

AliOS Things之romfs技術介紹

技術標籤：AliOS Things物聯網作業系統物聯網嵌入式實時作業系統HaaSAliOS Things 1、概述

go語言web開發系列之十七:用go-redis+lua實現順序自增的唯一id發號器

技術標籤：用go做web開發gogolangluaredisapi 一，安裝go-redis 1,從命令列執行: [email protected]:~$ go get -u github.com/go-redis/redis/v8

造輪子系列之RPC 1：如何從零開始開發RPC框架

RPC 框架是後端攻城獅永遠都繞不開的知識點，本系列 \"造輪子系列之RPC\"，手把手教大家如何打造自己的RPC框架。

C#開發BIMFACE系列40 服務端API之模型整合

BIMFACE二次開發系列目錄 【已更新最新開發文章，點選檢視詳細】 　　隨著建築資訊化模型技術的發展，越來越多的人選擇在雲端瀏覽建築模型。現階段的雲端模型瀏覽大多是基於檔案級別，一次只可以瀏覽一個模型檔案中

C#開發BIMFACE系列46 服務端API之離線資料包下載及結構詳解

BIMFACE二次開發系列目錄 【已更新最新開發文章，點選檢視詳細】 在前一篇部落格《C#開發BIMFACE系列45 服務端API之建立離線資料包》中通過呼叫介面成功的建立一個離線資料包

乘風破浪，遇見微軟低程式碼應用開發(LCDP)平臺之Microsoft Power Apps系列 - 2022年2-3月即將上線的新功能預告

Microsoft Power Apps是行業領先的低程式碼應用程式開發平臺，它支援Dynamics 365可擴充套件性、Microsoft 365自定義以及面向全球客戶的獨立自定義業務線應用程式。Power Apps通過一系列強大的低程式碼開發工具、M

kubeedge原始碼分析系列之整體架構

本系列的原始碼分析是在 commit da92692baa660359bb314d89dfa3a80bffb1d26c 之上進行的。 kubeedge是一個基於kubernetes構建的開放平臺，使能邊緣計算，將容器化應用編排功能擴充套件到邊緣的節點和裝置，併為雲和邊

1. 彤哥說netty系列之開篇（有個問卷調查）

你好，我是彤哥，本篇是netty系列的第一篇。 歡迎來我的公從號彤哥讀原始碼系統地學習原始碼&架構的知識。

kubeedge原始碼分析系列之edgecore（五）

本系列的原始碼分析是在 commit da92692baa660359bb314d89dfa3a80bffb1d26c 之上進行的。 cloudcore部分的原始碼分析是在kubeedge原始碼分析系列之整體架構基礎上展開的，如果沒有閱讀過kubeedge原始碼分析系列之整體

7. 彤哥說netty系列之Java NIO核心元件之Selector

——日拱一卒，不期而至！ 你好，我是彤哥，本篇是netty系列的第七篇。 簡介

6. 彤哥說netty系列之Java NIO核心元件之Buffer

——日拱一卒，不期而至！ 你好，我是彤哥，本篇是netty系列的第六篇。 簡介