记一次《C语言踩内存》问题定位有感

踩内存问题，个人认为算是比较容易出现但是有很难定位的问题，被踩者轻者功能瘫痪，重者一命呜呼，直接诱发死机。产生踩内存的的原因也比较多样，比较典型的有如下几种：

数组越界访问
字符串越界操作
直接操作野指针
操作了一块已经被释放了内存

这几种问题，单独说起来都是比较容易发现问题，但这些问题往往在某些环境中不会出现，但是在另外的环境下几乎是必现问题，这时定位起来难度就便增加了很多。这种情况往往是基本逻辑没有问题，在某些环境下(多核、异步、其他复杂环境等)逻辑上出现错误导致出现踩内存的问题。

下面我记录一下遇到过的踩内存问题，定位了很久… 记忆尤新，可能让我亢奋的是我定位时的骚操作。

1. 发现问题

发现问题比较简单，测试或者使用过程中突现了一个死机问题，通过core文件(获取其他信息)显示，第一想法是Oh, no, impossible, 这些死机问题怎么能死在这里？？？，代码不可能进入这个流程呀？，如果是这种情况，恭喜你中奖了，它基本上是因为踩内存引起的。

如果大概率是踩内存引起的死机问题，在仔细分析代码后没有什么效果的情况下，那么我们需要尝试去稳定复现此问题(可能很多条件不允许)

2. 复现问题出现的场景

想方设法找到必现条件。Why? 如果找不到必现条件，就算想验证我的想法都变得比较难，因为我不确定是它没有出现还是已经把它改好了。因此我认为找到必现条件几乎是必要的(目前还是一个小白)。

3. 分析代码逻辑

这个过程是贯穿整个问题的生命周期，甚至更长。分析代码并结合复现情景，把出现此问题的所有可能都进行分析，并进行尝试。尝试定位过程中不要求解决问题，**首先确定该问题是否为此问题引起的。**比如说：你怀疑由于提前释放了某一块内存，后面有操作了它，那么好，现在劳资就不释放此内存，然后对齐进行测试，确定是否出现此问题。如果问题依旧，那不好意思，咱们需要继续定位。但是如果不出现刚才的死机问题(可能由于没有释放内存出现OM了)，那恭喜你，基本就是它导致的了。

这里我说一下我当时干过的骚操作：

在我确定踩内存与某些结构有关的情况下，但是我又不知道谁踩内存，

struct ohMyGod{
	int *buff;
	int length;
	int cryptAlg;
	int cryptAlgLen;
	int hashAlg;
	int hashAlgLen;
}

于是乎我将上述的结构体改为这样：

struct ohMyGod{
	int unused[128];
	int *buff;
	int length;
	int cryptAlg;
	int cryptAlgLen;
	int hashAlg;
	int hashAlgLen;
	int unused[128];
}

我当时的想法：你小子不是要踩内存吗？劳资给你开一个VIP包间，你尽情的踩吧，我反正不使用这些内存。结果通过这种方式定位到了其中一个结构体。然后结合复现条件慢慢定位到了踩内存是由于新增的异步处理造成的。

4. 解决问题

踩内存的问题难度在于定位，解决往往比较简单。