Foreword : The C++ server used in the work, the slightest difference will cause the process to crash. Then the game needs to stop updating and maintenance, which will cause the loss of players. To summarize today, the server crash problem encountered before. Fortunately (burn incense and worship Buddha), my code only caused the internal network development server to crash, but the external network official server did not crash once. I am grateful, grateful, lucky, fluke.
One, array and vector subscripts are out of bounds
If someone summarizes each crash, I think this problem can account for 40%.
Just give you an example, the level package.
If our data structure is:
const int MAX_ROLE_LEVEL_REWARD_NUM = 3;
int m_role_level_reward_state[MAX_ROLE_LEVEL_REWARD_NUM];
The upper limit of the variable m_role_level_reward_state is 3. Assuming that we use a subscript greater than 3 for a certain reference, then the limit will be exceeded. The following wording is considered dangerous.
void UpdateRoleLevelReward(int index)
{
m_role_level_reward_state[index] = 1;
}
Because there is no judgment boundary. We can't control the external things, we can only ask our own code part to be safe. So we have to add the subscript range judgment:
void UpdateRoleLevelReward(int index)
{
if (index < 0 || index >= MAX_ROLE_LEVEL_REWARD_NUM) return;
m_role_level_reward_state[index] = 1;
}
If the periphery needs us to return status, then it can be written as a function that returns 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;
}
Second, the null pointer
The null pointer problem is estimated to account for 40%. This question is not a good example. Because the problems are scattered.
In order to avoid it, it is usually null before using the pointer.
Three, string formatting
Simply put, it is similar to the sprintf function in the C language, and may pass wrong parameters when formatting.
This problem often appears in the log system.
Fourth, the vector iterator fails.
Usually when traversing a vector, there is an erase operation in the loop. Need special attention.
Five, an endless loop.
This type of problem is not a good example. And the most difficult to check, in the above situation, there is usually a stack after a crash, and there will be ideas when looking at the stack with gdb.
The infinite loop will make the process CPU occupy 99%. The endless loop can only rely on the help of svn, which version is good, which version started to have problems, and what content has been modified, interrupt the troubleshooting.