總結----調試問題套路（經驗）

ISP效果經驗總結

基於最近平臺獨立分析排查宏視另外一個強光下，ISP偏紅震盪問題，最後由李志確認方案的案例。

結合平時解決問題的經驗，我的認爲在這種模塊負責人沒有時間狀況下，有些時候問題負責人根據必定的套路能夠嘗試着解決。不合理的地方，還請多多指教。

對ISP效果問題總結以下：

一、收集：根據圖像異常現象，打印常見ISP參數，觀察參數的變化狀況，這個過程要細心，不要放過任何蛛絲馬跡。

二、猜想：肯定某個參數異常變化的時間點是否和圖像異常的時間點吻合，若是吻合，那麼這個參數應重點跟蹤。（這個猜想有了依據）

三、求證：閱讀代碼，梳理參數的變化過程，在異常的地方，臨時調試性修正。查看結果，若是有效果，基本鎖定了問題。若是沒有效果，回到第1步。

四、修復：請模塊負責人確認問題，若是負責人認爲確實有問題並給出修復方案，問題負責人還需從正常程序設計邏輯上監控修復方案的合理性。          若是負責人認爲不是問題，應該解釋臨時修正有效果的緣由。

五、驗證：合理性修復後，測試整個系統驗證問題是否已修復。

ps:細心收集、大膽猜想、當心求證。對這個模塊經驗不足的人切記臆想型猜想，而後使用試錯的方法解決。

 

 

rt-thread: vi動態模塊線程被意外終止（內存異常）問題調試記錄

一、追蹤肯定動態模塊異常終止的緣由：

     動態模塊建立的camera驅動線程的線程控制塊出現異常，內核檢測到後，將這個動態模塊終止。

二、調試內存異常的過程：

     a、在問題內存先後申請測試10K內存做爲測試內存，問題依然存在，基本排除相鄰內存越界。

     b、懷疑是內存意外被線程釋放（線程刪除），放開內核調試打印，問題又不出現了，結合以前添加打印，有時異常，有時異常，隨機性比較大，因此更多是內存踩踏。      c、把不相關模塊都剔除，縮小範圍，從新梳理異常的現象，每次name被修改的比較隨機，可是同一個結構體內的type卻每次都被修改成0。

     d、將該線程控制塊每隔段時間打出來，基本能夠縮小範圍到函數DrvModule_Terminate_Task，只有在這個函數附近纔會出現，屏蔽其中某些子函數能夠恢復正常。可是不能肯定是具體哪一個子函數執行完纔出現的，不能定位到具體那條語句。

     e、那麼就和線程調度有關，執行某個子函數被切出去踩踏了，回來就異常，所有查看其子函數是否有任務切換，手動添加線程調度打印，發現確實有線程調度。

     f、閱讀理解驅動框架drv_module，發現rt_drv_entry線程退出後，會調用DrvModule_Free，想起rtt開發手冊有一條注：「在線程運行完成，自動結束的狀況下，系統會自動刪除線程，不須要再調用rt_thread_delete()函數接口」，可是手冊沒有說若是調用後會有什麼後果。

     g、爲了驗證這個猜想，在rt_drv_entry阻塞住，不退出，通過屢次測試，問題沒有再復現。

     h、結合代碼，確實是會在idle中將線程控制塊中的type清零，name不會清零，因此纔會出現c中描述的type每次都是0，name異常的比較隨機。

     i、想起劍平、興建原來也遇到thread_dele接口問題，他們經過修改rtt代碼繞過，經過驗證也是這個問題，因而糾正原來的修復方式。

三、問題原理描述：

     若是有子線程主動退出成爲殭屍線程，在任務切換時又先執行了idle線程，idle線程會把殭屍線程的控制塊釋放，而後再切迴應用主線程時，主線程又調用了rt_thread_delete接口釋放資源，這時rt_thread_delete接口裏仍然會意外訪問該線程控制塊，致使該內存訪問異常。

四、解決方案：

     修復驅動框架，避免子線程主動退出後，資源被idle線程釋放，而後主線程又調用rt_thread_delete訪問資源。

 

 

 

待續：

對錄像問題：

對網絡傳輸問題：

對寫卡問題：

對系統崩潰問題：