[Windows CE]debug正常,release不正常,你遇到了嗎?

反正我是遇到了,而且還遇到了多次. 曾經一度困擾了很久,終雩都一一解決仂.現在回過頭來看,其實,問題並不是想象中那麼妖,如果自己一開始就能保持一顆用頭腦思考的心的話,其實不用這麼長時間的.

卡住仂,下次繼續更新 .

OK.GO ON.
除了一些顯示的#ifdef DEBUG 之類的手誤導致的mistake之外,最常見的問題就是TIMING了.

有人說:DEBUG下大家一起慢,RELEASE大家一起快,為什麼還會有不同的時序出現呢?
回答:沒錯,的確大家都變快了,但是變快的步伐是不一定一致的!

很多在DEBUG下,因為各種串口輸出以及debug版本的核心,會隱藏很多其實是有問題的代碼. 貌似正常了,其實不然. 比如我上次遇到的一個問題: A和B都要互斥的訪問一個資源(CSPI),並且在不同的進程空間裡,所以需要加mutex進行資源訪問保護. A先初始化CSPI(CSPI_A配置),然後利用CSPI進行一些操作.然後B初始化,B插進來一腳獲得CSPI的控制許可權,又重新設定了CSPI(CSPI_B配置).此時,A如果要對CSPI訪問的話,只能乾瞪眼看著B在做.那麼,如果要讓A下次能繼續做的話,B在做完自己的事情之後,應該把CSPI的配置恢複程CSPI_A.這樣,才能神不知鬼不覺的讓A繼續往下做.當時,腦子一些短路了,恢複程配置B的那段代碼沒有放在mutex的保護地區內!!!但是這樣的代碼,在DEBUG下沒有問題,而RELEASE就發現不正常了.

還好這個錯誤犯的比較明顯,代碼又都是在一塊,仔細review一下就能發現不對了.那麼下一個問題就沒有這麼明顯了.
串口的收發是一個很經典的互斥問題(MD,又是互斥).不過因為是在同一進程裡(device.exe),所以也就不用mutex了,直接用critical_section即可.其實問題的原因就是臨界值保護的不恰當了.author的想法是正確的,但是在發函數裡明顯被無數個錯誤處理給混亂了.直接導致的現象就是RELEASE下一切正常的時序到了release下就不行了. 找到這個原因花了很長的時間,現在總結下來原因有2: 一,鑽牛角尖了.總以為是自己寫的那部分代碼有錯誤; 二, 經驗不足.沒能一直往正確的方向PUSH.

這些個問題解決了,加上前段時間折騰的SUSPEND問題,我有了一些感觸:
1 問題的產生都是有蛛絲馬跡的,找到兇器往往是破案的開始;
2 不要對任何代碼持絕對的相信,也不要對自己任何的能力持任何的否定;
3 能解決出現的問題是最好,但是事前的異常處理機制就應該完善.