遊戲編程中 令進程崩潰的錯誤總結

工做中使用的C++服務器，稍有不甚就會致使進程崩潰。那麼遊戲就須要中止更新維護，會形成玩家流失。

今天來總結一下，以前碰到過的服務器崩潰問題。很慶幸（燒香拜佛），個人代碼只形成過內網開發服的崩潰，外網正式服一次崩潰沒有，感激，感激，僥倖，僥倖。

 

1.數組和vector下標越界。

若是有人對每一次崩潰作總結，我想這個問題能佔百分之40。

隨便舉個例子，等級禮包。

若是咱們的數據結構是：

const int MAX_ROLE_LEVEL_REWARD_NUM = 3;
int m_role_level_reward_state[MAX_ROLE_LEVEL_REWARD_NUM];

m_role_level_reward_state這個變量的上限是3，假設咱們某一次引用用了大於3的下標，那麼就越界了。如下這種寫法，認爲是危險的。

void UpdateRoleLevelReward(int index)
{
    m_role_level_reward_state[index] = 1;  
}

由於沒有判斷邊界。外面的東西咱們控制不了，只能要求本身的代碼部分穩妥。因此咱們要加上下標範圍判斷：

void UpdateRoleLevelReward(int index)
{
    if (index < 0 || index >= MAX_ROLE_LEVEL_REWARD_NUM) return;
    m_role_level_reward_state[index] = 1;  
}

若是外圍須要咱們返回狀態，那麼能夠寫成返回bool的函數：

bool UpdateRoleLevelReward(int index)
{
    if (index < 0 || index >= MAX_ROLE_LEVEL_REWARD_NUM) return false;
    m_role_level_reward_state[index] = 1;  
    return ture;
}

2.空指針。

空指針問題估計也能佔到百分之40。這個問題不太好舉例。由於問題比較分散。

爲了不，一般會在使用指針前，判空。

 

3.字符串格式化

簡單講就是相似c語言裏的sprintf函數，可能出現格式化的時候傳了錯誤的參數。

這個問題常常出如今log系統裏面。

 

4.vector迭代器失效。

一般出如今遍歷vector時，循環裏面有erase操做。須要特別注意。

 

5.死循環。

這類問題也很差舉例。並且最難查，上面的狀況，崩潰以後一般會有個堆棧，用gdb看堆棧會有思路。

死循環會使得進程cpu佔用百分之99。死循環只能靠svn幫忙了，哪一個版本是好的，哪一個版本開始出的問題，修改了哪些內容，打斷點排查。

除了通常的循環裏，還會有一種遞歸沒出回溯的死循環。要是用了遞歸要特別當心回溯條件。