Linux編程時遇到Oops提示該如何排查?
各位工程師在Linux下開發(fā)程序時,有沒有遇到由于系統(tǒng)中存在某些小故障而跳出了“Oops”提示的情況,此時你是如何排查故障?一行行的查看代碼嗎?其實不用那么復雜,本文將為你介紹一種高效的Linux編程的故障排除方法。
本文引用地址:http://www.ex-cimer.com/article/201811/395128.htm在分析Oops之前,我們先來看以下這么一個例子,使用GPIO的中斷做掉電檢測,參考《嵌入式Linux開發(fā)教程下冊》的驅動框架,設計如下程序框圖:
這個框架設計之初的理想流程為:應用啟動->程序初始化->應用open設備->等待中斷事件,但實際項目開發(fā)時,往往發(fā)生許許多多不可預測的事情。如小王正在調Qt應用,發(fā)現(xiàn)老王的進程老在打印,那就不讓老王的進程開機自啟動,調了兩三天后,不定時地提示個Oops提示,小王按照“以前代碼不出現(xiàn),新加的出現(xiàn),那么起因絕對在新代碼內”的慣性思維,認為是新加的Qt導致的,然后小王就不斷測試,不斷查找bug中.......這樣就過去了十年。
但原因其實是小王沒有open設備,即驅動層沒有初始化定時器隊列,那么中斷處理函數(shù)中50ms觸發(fā)的隊列就為一個空值,空指針時Linux內核當然“哎呦”一下提醒你了,而不定時地提示其實就是因為電源不定時地松動,gpio檢測到掉電了所以觸發(fā)了中斷。
實際上,這樣的案例十分常見,原本想A->B->C,實際使用是A->D->C,又或者驅動中有某個變量忘記初始化等等,這時分析Oops就可以十分快速地解決問題。那接下來我們就用Linux中標準驅動去觸發(fā)一個Oops,對的你沒看錯,Linux內核標準源碼也存在這樣的異常,而且我們也可以去修復這樣的問題。
使用我司的EasyARM-iMX283開發(fā)板,內核源碼為光盤內的Linux-2.6.35.3.tar.bz2,編譯方法請參考光盤資料,我們需要把lcd的背光驅動修改為ko模式。
燒錄完新內核,加載新編譯出來的drivers/video/backlight/mxs_bl.ko文件就會提示以下Oops信息:
乍看之下,這段信息跟亂碼差不多,但只要你一層層地分析,你就會發(fā)現(xiàn),這些信息已經(jīng)告訴了我們錯誤的原因。接下來就開始我們的Oops分析之旅。
1、主要錯誤信息
用于提示錯誤的類型,這里表示使用空指針。
2、操作入口
用于提示錯誤的操作,這里表示加載mxs_bl模塊時出錯,對應于加載操作insmod mxs_bl.ko。
3、PC指針
用于提示出錯時的PC指針位置,PC指針即當前程序運行點的地址,這里提示表示錯誤函數(shù)為regulator_set_current_limit,偏移地址為0xc。
4、LR指針
用于提示出錯時的LR指針位置,LR指針即調用子函數(shù)的上一個函數(shù)名以及入口偏移量,這里表示上一個函數(shù)為set_bl_intensity,偏移地址為0xd8。即set_bl_intensity調用regulator_set_current_limit時出錯。
5、寄存器值
用于記錄出錯時各個寄存器的值,對于匯編比較熟悉的同志們可以研究一下這段信息。
6、出錯進程信息
用于提示出錯的進程id號與進程名稱。出錯進程為insmod, PID號2261,對于多任務系統(tǒng)中,可能存在多個PID調用同一個接口的情況。
7、出錯時的堆棧信息
用于提示出錯時堆棧內保存的寄存器信息,當程序由于中斷發(fā)生或子程序調用時,會執(zhí)行壓棧操作,即將運行環(huán)境保存到堆棧內,保證退出中斷或跳出子程序后,運行環(huán)境不發(fā)生改變。
而此處的堆棧信息即記錄了程序運行時的環(huán)境信息。從中我們可以找到許多LR地址,從而分析出函數(shù)調用關系,與下一段的信息有類似作用。
8、函數(shù)執(zhí)行的回溯關系
評論