C/C++动态分配连续空间，下标越界导致的free():invalid next size问题
昨天帮导师做的一个程序出了内存泄露的bug（在VS上程序运行一切正常，等return返回后才出错）
而且是程序运行结束后才出现的错误，在退出前一切代码都顺利执行完了，只是return之后出错。
之后我在Linux下重新编译运行程序，提示的信息更详细：
free(): invalid next size (normal)
然后下面显示Backtrace和Memory map等一大串错误信息。
最终调试发现问题在于，读取数据格式不对，导致字符串转换后的int小于0，下标越界。我只检查了上限N，没检查下限0。
那么问题来了，为什么动态分配的内存能访问下标为负的地方呢？来写几个程序测试下。
#include <iostream> using namespace std; int main() { const int N = 5; int* p = new int[N]; p[-1] = 1; p[-2] = 3; for (int i = -4; i < 0; i++) { cout << p[i] << " "; } cout << endl; delete[] p; return 0; }
0 0 3 1 *** Error in `./a.out': munmap_chunk(): invalid pointer: 0x0000000000ed6c20 ***
可以发现在n<0时，p[n]仍然可以访问，但是最终结束时会出错。
再看看下面这份代码
#include <iostream> using namespace std; int main() { const int N = 5; int* p = new int[N]; p[N] = 100; cout << p[N] << endl; delete[] p; return 0; }
运行结果是100，并且没任何问题。
也就是说，C/C++可以访问显式申请的内存之外的内存空间，它们可能是库函数隐式申请的，比如之所以上面一份代码正常运行，但是异常退出，下面一份代码正常运行、正常退出。原因是，new（会调用内置的allocator）动态申请一片内存时，会在返回的指针p之前记录下申请的内存大小，这样之后用delete释放new申请的内存时会隐式查找记录的内存大小，从而知道该释放多少内存。所以才可以用delete[]而不是delete[N]。
同理，使用malloc()时也会在返回的指针之前的某个地址记录申请内存大小，这样free()就会在释放内存时找到这个记录分配大小的地址，然后知道释放多少。
C/C++不会像java一样在编译层面检查下标是否越界，所以如果不在代码里手动检查，下标越界可能会导致库函数需要用到的内存地址被我们误修改，从而使库函数出错。
明白了这一点后，new和delete配对，new[]和delete[]配对，malloc()和free()配对的原因也理解了。每个内存分配器都有自己的申请和释放的策略，比如说记录申请的空间，我可以在一个字节的前几位记录，也可以在一个字节的后几位记录，如果申请和释放的规则不一致的话就会造成错误的后果。
回顾之前我的两篇类似的博客
【free() invalid next size】谨慎地在C++的类中存储指针来方便访问其他节点
第一篇，用cvLoadImage申请内存，却用delete释放内存，两者记录申请内存大小的策略不同，因此释放出错。
第二篇，记录了vector之前的内部指针p，但是vector重新分配内存后内部指针变了，再访问p指向的位置就物是人非了。和我这次很像的是，之前那篇我自信满满地认为vector不会重新分配内存，即认为push_back的次数小于reserve预留的大小，这篇则是自信满满地认为下标肯定为非负数，因为之前的下标是用字符串转换而成的，比如"0a"对应的就是10，我认为肯定会不小于0，但是这些下标是从1开始的，所以我将字符串转换后的下标都减了1，这样的话错误的输入比如"00"在转换后就是-1，下标越界。
总结下来，C/C++下标越界确实是个麻烦，有时候像这种“自信满满”的预测会导致运行错误，所以最佳的实践方式是写出便于调试的代码。
1、尽可能使用STL容器，STL容器在下标越界时会在访问时就出错，不会让程序继续运行；
2、使用RAII来让申请和释放配对；
3、调试时若想获得更详细的信息，在所有需要用下标的位置都加上检查语句。
