错误：免费（）：无效的下一个大小（快）：
这是什么奇怪的错误，我得到了什么？ 我在Ubuntu 10.10上使用g ++编译C ++。 当我运行可执行文件时，它会随机popup（可能是8小时内的2次，每10小时编译一次）。 但是，如果我干净并重新编译，大部分时间都会消失。
*** glibc detected *** ./emailQueue.app: free(): invalid next size (fast): 0x0000000001c40270 *** ======= Backtrace: ========= /lib/libc.so.6(+0x774b6)[0x7f490d95e4b6] /lib/libc.so.6(cfree+0x73)[0x7f490d964c83] ./emailQueue.app[0x401f47] /lib/libc.so.6(__libc_start_main+0xfe)[0x7f490d905d8e] ./emailQueue.app[0x401cc9] ======= Memory map: ======== 00400000-0040d000 r-xp 00000000 08:01 1311132 /home/server/Projects/email/emailQueue.app 0060d000-0060e000 r--p 0000d000 08:01 1311132 /home/server/Projects/email/emailQueue.app 0060e000-0060f000 rw-p 0000e000 08:01 1311132 /home/server/Projects/email/emailQueue.app 01c40000-01c82000 rw-p 00000000 00:00 0 [heap] 7f4908000000-7f4908021000 rw-p 00000000 00:00 0 7f4908021000-7f490c000000 ---p 00000000 00:00 0 7f490ce52000-7f490ce5e000 r-xp 00000000 08:01 1051251 /lib/libnss_files-2.12.1.so 7f490ce5e000-7f490d05d000 ---p 0000c000 08:01 1051251 /lib/libnss_files-2.12.1.so 7f490d05d000-7f490d05e000 r--p 0000b000 08:01 1051251 /lib/libnss_files-2.12.1.so 7f490d05e000-7f490d05f000 rw-p 0000c000 08:01 1051251 /lib/libnss_files-2.12.1.so 7f490d05f000-7f490d075000 r-xp 00000000 08:01 1048770 /lib/libz.so.1.2.3.4 7f490d075000-7f490d275000 ---p 00016000 08:01 1048770 /lib/libz.so.1.2.3.4 7f490d275000-7f490d276000 r--p 00016000 08:01 1048770 /lib/libz.so.1.2.3.4 7f490d276000-7f490d277000 rw-p 00017000 08:01 1048770 /lib/libz.so.1.2.3.4 7f490d277000-7f490d28e000 r-xp 00000000 08:01 1051248 /lib/libnsl-2.12.1.so 7f490d28e000-7f490d48d000 ---p 00017000 08:01 1051248 /lib/libnsl-2.12.1.so 7f490d48d000-7f490d48e000 r--p 00016000 08:01 1051248 /lib/libnsl-2.12.1.so 7f490d48e000-7f490d48f000 rw-p 00017000 08:01 1051248 /lib/libnsl-2.12.1.so 7f490d48f000-7f490d491000 rw-p 00000000 00:00 0 7f490d491000-7f490d49a000 r-xp 00000000 08:01 1051244 /lib/libcrypt-2.12.1.so 7f490d49a000-7f490d69a000 ---p 00009000 08:01 1051244 /lib/libcrypt-2.12.1.so 7f490d69a000-7f490d69b000 r--p 00009000 08:01 1051244 /lib/libcrypt-2.12.1.so 7f490d69b000-7f490d69c000 rw-p 0000a000 08:01 1051244 /lib/libcrypt-2.12.1.so 7f490d69c000-7f490d6ca000 rw-p 00000000 00:00 0 7f490d6ca000-7f490d6e2000 r-xp 00000000 08:01 1051256 /lib/libpthread-2.12.1.so 7f490d6e2000-7f490d8e1000 ---p 00018000 08:01 1051256 /lib/libpthread-2.12.1.so 7f490d8e1000-7f490d8e2000 r--p 00017000 08:01 1051256 /lib/libpthread-2.12.1.so 7f490d8e2000-7f490d8e3000 rw-p 00018000 08:01 1051256 /lib/libpthread-2.12.1.so 7f490d8e3000-7f490d8e7000 rw-p 00000000 00:00 0 7f490d8e7000-7f490da61000 r-xp 00000000 08:01 1048743 /lib/libc-2.12.1.so 7f490da61000-7f490dc60000 ---p 0017a000 08:01 1048743 /lib/libc-2.12.1.so 7f490dc60000-7f490dc64000 r--p 00179000 08:01 1048743 /lib/libc-2.12.1.so 7f490dc64000-7f490dc65000 rw-p 0017d000 08:01 1048743 /lib/libc-2.12.1.so 7f490dc65000-7f490dc6a000 rw-p 00000000 00:00 0 7f490dc6a000-7f490dc7f000 r-xp 00000000 08:01 1048655 /lib/libgcc_s.so.1 7f490dc7f000-7f490de7e000 ---p 00015000 08:01 1048655 /lib/libgcc_s.so.1 7f490de7e000-7f490de7f000 r--p 00014000 08:01 1048655 /lib/libgcc_s.so.1 7f490de7f000-7f490de80000 rw-p 00015000 08:01 1048655 /lib/libgcc_s.so.1 7f490de80000-7f490df02000 r-xp 00000000 08:01 1051246 /lib/libm-2.12.1.so 7f490df02000-7f490e101000 ---p 00082000 08:01 1051246 /lib/libm-2.12.1.so 7f490e101000-7f490e102000 r--p 00081000 08:01 1051246 /lib/libm-2.12.1.so 7f490e102000-7f490e103000 rw-p 00082000 08:01 1051246 /lib/libm-2.12.1.so 7f490e103000-7f490e1eb000 r-xp 00000000 08:01 4853329 /usr/lib/libstdc++.so.6.0.14 7f490e1eb000-7f490e3ea000 ---p 000e8000 08:01 4853329 /usr/lib/libstdc++.so.6.0.14 7f490e3ea000-7f490e3f2000 r--p 000e7000 08:01 4853329 /usr/lib/libstdc++.so.6.0.14 7f490e3f2000-7f490e3f4000 rw-p 000ef000 08:01 4853329 /usr/lib/libstdc++.so.6.0.14 7f490e3f4000-7f490e409000 rw-p 00000000 00:00 0 7f490e409000-7f490e5c7000 r-xp 00000000 08:01 4851315 /usr/lib/libmysqlclient.so.16.0.0 7f490e5c7000-7f490e7c7000 ---p 001be000 08:01 4851315 /usr/lib/libmysqlclient.so.16.0.0 7f490e7c7000-7f490e7cc000 r--p 001be000 08:01 4851315 /usr/lib/libmysqlclient.so.16.0.0 7f490e7cc000-7f490e816000 rw-p 001c3000 08:01 4851315 /usr/lib/libmysqlclient.so.16.0.0 7f490e816000-7f490e817000 rw-p 00000000 00:00 0 7f490e817000-7f490e837000 r-xp 00000000 08:01 1048597 /lib/ld-2.12.1.so 7f490ea15000-7f490ea1c000 rw-p 00000000 00:00 0 7f490ea33000-7f490ea37000 rw-p 00000000 00:00 0 7f490ea37000-7f490ea38000 r--p 00020000 08:01 1048597 /lib/ld-2.12.1.so 7f490ea38000-7f490ea39000 rw-p 00021000 08:01 1048597 /lib/ld-2.12.1.so 7f490ea39000-7f490ea3a000 rw-p 00000000 00:00 0 7fffb85b9000-7fffb85da000 rw-p 00000000 00:00 0 [stack] 7fffb85ff000-7fffb8600000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] Aborted 这意味着你有一个内存错误。 你可能试图free一个没有被malloc分配的指针（或者delete一个不是由new创build的对象），或者你可能试图多次free / delete这个对象。 您可能会溢出缓冲区或以其他方式写入您不应写入的内存，从而导致堆损坏。
任何编程错误都可能导致此问题。 您需要使用debugging器，获取回溯，并查看发生错误时程序正在执行的操作。 如果失败了，并且确定在之前的某个时间点已经损坏了堆，那么可能需要进行一些痛苦的debugging（如果项目足够小以至于可以逐个处理，那么可能不会太痛苦）。
我遇到了同样的问题，即使我没有在我的程序中做任何dynamic的内存分配，但是我正在访问一个向量的索引而没有为它分配内存。 所以，如果情况相同，最好使用resize()分配一些内存，然后访问向量元素。
我们需要代码，但是当你试图从一个没有分配的指针free()内存时，通常会popup这个代码。 这种情况经常发生在双重释放时。
我遇到了类似的错误。 这是一个匆忙做noob错误。 整数数组没有声明大小int a []然后试图访问它。 如果C ++编译器在main中，它应该很容易发现这样的错误。 然而，由于这个特定的int数组是在一个对象中声明的，所以它正在创build与我的对象（许多对象正在创build）同时被创build，并且编译器正在抛出一个free（）：无效的下一个大小（正常）错误。 我想到了2个解释（如果有人知道更多，请给我启发）：1）这导致一些随机的内存分配给它，但由于这是无法访问它释放所有其他堆内存只是试图find这个int。 2）程序所需要的内存几乎是无限的，分配它是释放所有其他内存。
一个简单的：
int* a; class foo{ foo(){ for(i=0;i<n;i++) a=new int[i]; }
解决问题。 但是，它花了很多时间来debugging，因为编译器不能“真正”发现错误。
如果您正在尝试为指针数组分配空间，如
char** my_array_of_strings; // or some array of pointers such as int** or even void**
那么当为n个指针分配空间时，您需要考虑字大小（64位系统中的8位，32位系统中的4个字节）。 指针的大小与您的单词大小相同。
所以，虽然你可能希望为n个指针分配空间，但实际上你需要n次8或4（分别用于64位或32位系统）
为了避免为8个字节的n个元素溢出分配的内存：
my_array_of_strings = (char**) malloc( n * 8 ); // for 64-bit systems my_array_of_strings = (char**) malloc( n * 4 ); // for 32-bit systems
这将返回一个由n个指针组成的块，每个指针包含8个字节（如果您使用的是32位系统，则为4个字节）
我已经注意到，当你没有补偿字的大小时，Linux会允许你使用所有的n个指针，但是当你试图释放内存的时候，它会发现它的错误，并且会给出一个相当糟糕的错误。 这是一个糟糕的，当你分配内存溢出，许多安全问题在于等待。
我遇到了这样一种情况：代码绕过STL的API，并在有人resize时写入数组。 在这里添加断言抓住了它：
void Logo::add(const QVector3D &v, const QVector3D &n) { GLfloat *p = m_data.data() + m_count; *p++ = vx(); *p++ = vy(); *p++ = vz(); *p++ = nx(); *p++ = ny(); *p++ = nz(); m_count += 6; Q_ASSERT( m_count <= m_data.size() ); }
