今天遇到一個(gè)比較有意思的bug, 這里簡(jiǎn)單記錄下。
Bug的癥狀是通過拖拉邊框把我們客戶端主窗口拖小之后，再最大化，會(huì)發(fā)現(xiàn)窗口顯示有問題， 看起來像是刷新問題， 有些地方顯示的不對(duì)了。
這里要說明的是我這里的主窗口是非常復(fù)雜的窗口， 里面集成了很多組件(cpmponent)，有很多層的子窗口。 這個(gè)問題只有在特定條件下才會(huì)發(fā)生， 正常情況下都是好的。
遇到這種問題，我們?cè)趺刺幚恚?nbsp;
首先當(dāng)然是觀察癥狀， 究竟是刷新問題， 還是Layout出錯(cuò)了。
我們可以通過Spy++查看窗口層次是不是正確， 窗口位置是不是對(duì)的。
查看結(jié)果是窗口的層次和Layout位置都沒有問題。
既然我們這里遇到的刷新問題，所以我們要從WM_PAINT消息著手， 我們通過Spy++查看相關(guān)窗口的WM_PAINT是不是正確。
很快我們就會(huì)發(fā)現(xiàn)某個(gè)窗口正在不停地收到WM_PAINT消息， 很可能與我們的bug有關(guān)。
一個(gè)窗口不停的收到WM_PAINT重畫， 無非大概有幾類原因：
正常情況是我們正在做動(dòng)畫， 可能是通過定時(shí)器之類的東西讓窗口不停地InvalidateRect重畫某塊區(qū)域， 我們的窗口明顯不屬于這種情況。
異常情況有時(shí)是WM_PAINT消息里我們的消息處理函數(shù)在某些條件下直接返回了，從而沒有調(diào)用BeginPaint告訴窗口無效區(qū)域已經(jīng)有效， 這樣會(huì)因?yàn)橐驗(yàn)榇翱谝恢庇袩o效區(qū)域存在，導(dǎo)致窗口一直收到WM_PAINT消息。
還有一種異常情況情況是我們是在WM_PAINT消息里調(diào)用BeginPaint后又調(diào)用了InvalidateRect, 這樣會(huì)導(dǎo)致窗口后面會(huì)再次收到WM_PAINT消息， 最后窗口陷入WM_PAINT的死循環(huán)。
那么我們這里的問題窗口屬于哪類？ 用什么方法可以判斷出來？
注意到這里關(guān)鍵的三個(gè)API：BeginPaint， EndPaint, InvalidateRect的第一個(gè)參數(shù)都是窗口句柄， 我們可以通過WinDbg的API斷點(diǎn)來跟蹤執(zhí)行過程， Attach WinDbg到我們的主窗口進(jìn)程，比如我們的窗口句柄是0x209A0, 我們可以這樣設(shè)置API斷點(diǎn)：
bp USER32!NtUserInvalidateRect ".if(dwo(@esp+0x4)==0x209A0) {kv;gc} .else {gc}"
bp USER32!NtUserBeginPaint ".if(dwo(@esp+0x4)==0x209A0) {kv;gc} .else {gc}"
bp USER32!NtUserEndPaint ".if(dwo(@esp+0x4)==0x209A0) {kv;gc} .else {gc}"
上面的條件斷點(diǎn)表示，當(dāng)調(diào)用我們的對(duì)應(yīng)的API，并且第一個(gè)參數(shù)(窗口句柄)是我們的目標(biāo)窗口時(shí)，打印堆棧。
很快我定位出Bug發(fā)生的原因了， 條件斷點(diǎn)顯示了API如下的調(diào)用次序：
BeginPaint->InvalidateRect->InvalidateRect->EndPaint
找到Bug的原因后，然后把Bug assign給該模塊的負(fù)責(zé)人。 （看我夠意思吧，不僅找到原因，還把調(diào)用棧都提供了）
另外 ，后面還發(fā)現(xiàn)這個(gè)bug發(fā)生時(shí)窗口的某些行為會(huì)不對(duì)， 測(cè)試發(fā)現(xiàn)原因是所有窗口的定時(shí)器都不能正常工作了。
關(guān)于這個(gè)問題， 你能想到原因嗎？
如果看了還想不到， 重點(diǎn)看第4條。
最后， 簡(jiǎn)單總結(jié)下：計(jì)算機(jī)的好處是它永遠(yuǎn)不會(huì)欺騙你， 它只會(huì)按部就班的執(zhí)行， 所以很多看似奇怪(甚至看似不可思議的問題)， 只要你理解了程序背后的機(jī)制原理，都是可以找出根本原因的。
posted on 2014-05-30 23:18
Richard Wei 閱讀(2707)
評(píng)論(2) 編輯 收藏 引用 所屬分類:
windbg