关于malloc函数死机的问题

自打开了博客，还没动过笔，最近一直在琢磨着写点啥，今天就来了。

直接进入正题吧，相信使用C语言进行开发的，无论是嵌入式，还是PC应用balabala，malloc()跟free()结对使用都是家常便饭，那么问题来了，测试妹子昨天在撸主的软件上玩出个这样的现象，板子为机顶盒，妹子拿着闪迪的U盘插上去，然后来回切啊切，播放多媒体啊播放，然后切到视频上，挂掉了。立刻反馈给撸主，撸主当时颇为震惊，多少次撸主操作U盘都没有问题，偏偏这次就挂鸟？然后撸主开始了Debug过程。

撸主使用GDB找死机位置，结果你猜怎么着？多次死在malloc()函数，偶尔死在free()，这下可急坏了，软件可是要生产的，这要是让客户玩出来......问题就大了！

经过不断的探索，终于找出了原因，现在就跟拿出来说一下：

首先，malloc()跟free()在一个内核机制健全，C库完善的环境下，函数本身是不会引起死机问题的，除非你恶意操作。那么问题在哪呢？

撸主窃以为程序在内存跑动时候，malloc是在内存的管理机制上来分配动态内存的，那么malloc可以挂掉一个程序，必定是惹到了一个“恶意”的内存，那么这块内存一定不是栈、静态内存或者其他的内存，所以慢慢地找下去，会发现，其实位置大致在动态内存区。

到底哪个东西在动态内存，影响了它？撸主的代码是一个比较大的工程，光这个函数内就有若干个指针，malloc、free等，然后开始在上下文找啊找，终于在调用的函数中的函数中找到一个指针，这家伙在申请完内存后，开始跑，开辟的N个字节的动态内存，但是实际上指针在跑的时候跑到了N+1个字节的地址，但是这块内存后面应该都是废区或者说没有其他数据、内容，当时并没有错误，但是当这个挂掉整个程序的malloc开始执行时，操作系统将它安排在那块“恶意”内存后面，操作系统之前只知道那个指针申请了N个字节，并不管它操作多少字节，然后直接将malloc申请的内存安排在那个N个字节后面，然后......想必大家都知道了，两个互不相干的指针干到了一块，肯定挂掉了.......

所以撸主就在跑出N+1个字节地址的指针上，多申请了几个字节，然后就好了，至于free死机，撸主窃以为程序在跑的时候，因为操作是不一样的，free打算去释放那个跑飞了的指针，结果.....就挂掉了.....

得到的个人结论就是，在不确定是否使用多少大小的时候，尽量多申请两个数据长度，免得你的指针跑飞了