您好,登錄后才能下訂單哦!
問題及現象
此前,調試cocos2d-x + CocoStudio游戲程序過程中遇到一個運行時錯誤。通過調用堆棧來看,錯誤指針停在~CCNodeRGBA()。
分析1
CCNodeRGBA是一個繼承自CCNode的子類,其主要是增加了與結點透明度相關的屬性控制功能。
class CC_DLL CCNodeRGBA : public CCNode, public CCRGBAProtocol
CCNodeRGBA是CCSprite和Widget(即UIWidget)的直接父類。因此,出現錯誤對象應當與CCSprite和Widget對象及可能的子類對象有關。
分析2
具體的錯誤堆棧內容我就不截圖了。從棧中層次分析,最可能是析構結點過程(一級級的析構,這是C++的析構規則,由子到父到祖父再到...)的最后產生了上述錯誤,大致可以估計出現了內存崩潰。
分析3
既然問題初步定位在內存崩潰,那么很可能與指針使用相關。回想前段時間(及很早以前--其實這部分代碼很早前就有了)感覺系統運行正常--當然是還在沒有增加新近添加的功能之前。
那么,怎么盡快分析出BUG?代碼近5000行!好在絕大部分都已經運行起來,于是我從測試實例入手(不敢直接使用縮小范圍法:即由原來的200個模塊縮小(主要是通過注釋屏蔽的方法)到想測試的100個模塊)。GOOD!在最簡單的操作測試中,新增加功能正常!這給了我極大鼓勵!
于是,我繼續使用測試實例法,并且把新增加功能一個個測試(反復進行)。最終,范圍逐漸定位在一個大致的實現算法上。
問題解決
問題出在:C++野指針問題!相關代碼如下:
//此前有聲明:Card* Cells[4]={NULL}; Cells[col]= (Card*)TableauPiles[whichColumnForCC]->lastObject(); Card* t2=Cells[col]; Cells[col]->setPosition(m_pCurNode->getChildByTag(10006+col)->getPosition()); m_pCurNode->reorderChild(Cells[col],++zIndexForAll); Cells[col]->setPosition(m_pCurNode->getChildByTag(10006+col)->getPosition()); m_pCurNode->reorderChild(Cells[col],++zIndexForAll); TableauPiles[whichColumnForCC]->removeLastObject();
問題出在第一句與最后一句。第一句的意義是指:把Cells[col]指針指向一個已經內存分配的Card對象所在位置。而最后一句,把這個對象對應內存釋放掉了!于是Cells[col]指向的對象成了僵尸。
僵尸很可怕!我們大家都看過類似體裁的故事吧!我的游戲中,Cells[col]指針的精靈仍然可以在屏幕上移動,好像是正常的精靈一樣!!!這也正是我直接使用以前的代碼而現在遲遲沒有發現的原因之一(當然,根本原因還與本人C++功能有密切關系)。
進一步分析
大家都知道CCArray這個數據類型很好使用,因為它繼承自STL中現有結構,而且效率明確提高,特別是其提供了大量的簡化數組操作的方法。但是,也有不足:在使用CCArray時,有關retain問題我就不再重復了--網絡上有的是。在普通的cocos2d-x編碼中,使用了retain那么在最后就要調用相應的release;但是,當你配合使用CocoStudio UI編輯器或者場景編輯器進行開發時就不需要(也不能夠)調用release了。有關細節,Hanrea告訴我UI解析器在釋放場景內容時自動處理了。當然,我還沒有分析他們的源代碼,所以只是這么結論了。當然,在我前段時間花費不少時間克服的問題也證明了這一點。
接下來,removeLastObject這個方法有一個bool類型參數,默認為true,即釋放掉相應內存。源碼如下:
void CCArray::removeLastObject(bool bReleaseObj) { CCAssert(data->num, "no objects added"); ccArrayRemoveObjectAtIndex(data, data->num-1, bReleaseObj); }
再跟蹤下去:
void ccArrayRemoveObjectAtIndex(ccArray *arr, unsigned int index, bool bReleaseObj/* = true*/) { CCAssert(arr && arr->num > 0 && index < arr->num, "Invalid index. Out of bounds"); if (bReleaseObj) { CC_SAFE_RELEASE(arr->arr[index]); } arr->num--; unsigned int remaining = arr->num - index; if(remaining>0) { memmove((void *)&arr->arr[index], (void *)&arr->arr[index+1], remaining * sizeof(CCObject*)); } }
注意上面第一個if語句,當參數為true時,把相應內存真正釋放掉了。請參考我們上面的游戲代碼。
最后,糾正一下錯誤,很簡單,把上面最后一句修改如下即可:
TableauPiles[whichColumnForCC]->removeLastObject(false);
顯然,傳遞參數false就是只在本數組中進行了下標調整(arr->num也比原來減小了1),并沒有進行最后一個結點對應的內存釋放。反而,最后一個數組結點對應內存被Cells[col]這個指針接收下了。于是,避免了一個野指針(僵尸)事件,一切自然OK!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。