DEBUG 記一次野指標除錯

2021-05-25 02:15:24 字數 1227 閱讀 7525

關於野指標,我覺得最可怕的情況就是,它在程式大部分時候都不會出錯,當你專案越來越大的時候,可能就會出現各種隨機性詭異錯誤了,而這時你壓根就不會想到是自己很久前的一次疏忽。

我在shero裡用的實體框架是這樣的,邏輯物件為entity,視覺物件為visual,visual根據entity來渲染自己,所以它儲存了乙個entity指標m_pentity。

更新流程是:

entity->update();

visual->update();

當entity需要刪除時,將m_candel置為true。

所以在entitymanager的更新裡就是這樣:

if (m_candel)  delete pentity;

但是viusual怎麼辦呢,entity沒有儲存visual指標,沒法通知它需要刪除,所以我是這樣更新的:

if(m_pentity->candel())  delete pvisual;

倒霉的是,當m_pentity為野指標後,m_pentity->candel()還真為true。。所以一直沒發覺。

debug就是這樣,源頭找到後就會覺得很簡單,如果就這樣自大的一笑了之,那以後肯定繼續被它虐。所以重要的還是對過程的一些反思:

首先,我這種情況就會產生一些隨機性詭異錯誤,而且源頭是在其他模組裡,比如這個bug很早以來就一直存在,而且很早前我也發現過乙個由於它導致的堆損壞。當時我查到的源頭是在audio模組裡,而且只是某個怪物的音效才會出錯。所以,我當時的結論是:嗯,這個怪物的音效檔案有誤,以後給它換過就沒問題了。

後來,又是cegui出錯,而且這次不是提示堆損壞,直接run time error指標錯誤。鬱悶,換回win7,執行居然一切正常,懷疑又是**的庫版本不對,想半天沒有結果。

又蛋疼的持續2天除錯一些根本沒有問題的模組。後來,採用注釋法把這些出錯的模組注釋掉,回到了很久前的乙個遊戲結構。再採用極限法,加大產生entity的速度,然後也是不停刪除他們。 果然,找到了其實是自己很久前的一次野指標疏忽,導致這麼多詭異錯誤。。。

總結幾點:

vs提供了堆檢查機制,但是它是有限的,比如野指標操作導致記憶體錯亂這種情況,它很難檢查到。

xp下執行出現run time error,win7下執行正常,這是因為win7的堆管理要先進一些,野指標導致的錯誤要難觸發一些。囧,網上搜了很久,貌似還沒人出現過這種情況。

safe_delete能避免一些野指標錯誤,但是不要忘了,指標可能賦值在其他地方,你用safe_delete把指標置0後,其他地方的指標還是野指標。

記一次除錯

這是我最近幾個月來遇到的最棘手的乙個問題 昨天花了4個小時找出第一層次的原因 這個糾結啊,本來和老婆說好準時下班回家吃飯的,結果被這個問題拖了老久。這是乙個gradle的plugin,用來resolve公司內部的dependency的,弄完了跑測試專案的,拋乙個npe,而且npe還不在自己的 裡面。...

記一次除錯

這是我最近幾個月來遇到的最棘手的乙個問題 昨天花了4個小時找出第一層次的原因 這個糾結啊,本來和老婆說好準時下班回家吃飯的,結果被這個問題拖了老久。這是乙個gradle的plugin,用來resolve公司內部的dependency的,弄完了跑測試專案的,拋乙個npe,而且npe還不在自己的 裡面。...

記一次nginx module 除錯

參考了 先進入nginx工作目錄 usr local nginx sbin 使用gdb q tui q選項是以安靜模式啟動,不顯示gdb版本等資訊。tui選項可以顯示 介面 然後在gdb中啟動nginx shell nginx 啟動之後,可以檢視當前nginx中的程序號 shell pidof ng...