C++ 错误：free()：下一个尺寸无效（快速）：
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/4729395/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Error: free(): invalid next size (fast):
提问by Josh
What is this strange error I'm getting? I'm compiling C++ using g++ on Ubuntu 10.10. It pops up randomly when I run the executable (maybe 2 times in 8 hours, with 10 compiles an hour). However, if I make clean and recompile it goes away most of the time.
我得到的这个奇怪的错误是什么？我正在 Ubuntu 10.10 上使用 g++ 编译 C++。当我运行可执行文件时它会随机弹出（可能在 8 小时内出现 2 次，每小时编译 10 次）。但是，如果我 make clean 并重新编译，它大部分时间都会消失。
*** 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
回答by James McNellis
It means that you have a memory error. You may be trying to freea pointer that wasn't allocated by malloc(or deletean object that wasn't created by new) or you may be trying to free/deletesuch an object more than once. You may be overflowing a buffer or otherwise writing to memory to which you shouldn't be writing, causing heap corruption.
这意味着您有内存错误。您可能正在尝试free指向未分配的指针malloc（或未delete创建的对象new），或者您可能多次尝试free/delete这样的对象。您可能正在溢出缓冲区或以其他方式写入您不应该写入的内存，从而导致堆损坏。
Any number of programming errors can cause this problem. You need to use a debugger, get a backtrace, and see what your program is doing when the error occurs. If that fails and you determine you have corrupted the heap at some previous point in time, you may be in for some painful debugging (it may not be too painful if the project is small enough that you can tackle it piece by piece).
任何数量的编程错误都可能导致此问题。您需要使用调试器，获取回溯，并查看发生错误时程序正在执行的操作。如果失败并且您确定您在之前的某个时间点损坏了堆，您可能会进行一些痛苦的调试（如果项目足够小，您可以逐个解决它，这可能不会太痛苦）。
回答by vvs14
I encountered the same problem, even though I did not make any dynamic memory allocation in my program, but I was accessing a vector's index without allocating memory for it.
So, if the same case, better allocate some memory using resize()and then access vector elements.
我遇到了同样的问题，尽管我没有在我的程序中进行任何动态内存分配，但是我访问了一个向量的索引而没有为它分配内存。因此，如果是相同的情况，最好使用resize()然后访问向量元素分配一些内存。
回答by orlp
We need the code, but that usually pops up when you try to free()memory from a pointer that is not allocated. This often happens when you're double-freeing.
我们需要代码，但是当您尝试free()从未分配的指针中获取内存时，通常会弹出该代码。当您进行双重释放时，通常会发生这种情况。
回答by george
If you are trying to allocate space for an array of pointers, such as
如果您尝试为指针数组分配空间，例如
char** my_array_of_strings; // or some array of pointers such as int** or even void**
then you will need to consider word size (8 bytes in a 64-bit system, 4 bytes in a 32-bit system) when allocating space for n pointers. The size of a pointer is the same of your word size.
那么在为 n 个指针分配空间时，您将需要考虑字大小（64 位系统中为 8 个字节，32 位系统中为 4 个字节）。指针的大小与您的字大小相同。
So while you may wish to allocate space for n pointers, you are actually going to need n times 8 or 4 (for 64-bit or 32-bit systems, respectively)
因此，虽然您可能希望为 n 个指针分配空间，但实际上您将需要 n 次 8 或 4（分别针对 64 位或 32 位系统）
To avoid overflowing your allocated memory for n elements of 8 bytes:
为避免为 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
This will return a block of n pointers, each consisting of 8 bytes (or 4 bytes if you're using a 32-bit system)
这将返回一个包含 n 个指针的块，每个指针由 8 个字节组成（如果您使用的是 32 位系统，则为 4 个字节）
I have noticed that Linux will allow you to use all n pointers when you haven't compensated for word size, but when you try to free that memory it realizes its mistake and it gives out that rather nasty error. And it is a bad one, when you overflow allocated memory, many security issues lie in wait.
我注意到 Linux 将允许您在未补偿字长时使用所有 n 个指针，但是当您尝试释放该内存时，它意识到它的错误并给出了相当严重的错误。这是一个糟糕的问题，当您分配的内存溢出时，许多安全问题都在等待。
回答by peter karasev
I encountered such a situation where code was circumventing STL's api and writing to the array unsafely when someone resizes it. Adding the assert here caught it:
我遇到过这样的情况，当有人调整数组大小时，代码绕过 STL 的 api 并不安全地写入数组。在此处添加断言抓住了它：
void Logo::add(const QVector3D &v, const QVector3D &n)
{
GLfloat *p = m_data.data() + m_count;
*p++ = v.x();
*p++ = v.y();
*p++ = v.z();
*p++ = n.x();
*p++ = n.y();
*p++ = n.z();
m_count += 6;
Q_ASSERT( m_count <= m_data.size() );
}
回答by Arkantos
I encountered a similar error. It was a noob mistake done in a hurry. Integer array without declaring size int a[] then trying to access it. C++ compiler should've caught such an error easily if it were in main. However since this particular int array was declared inside an object, it was being created at the same time as my object (many objects were being created) and the compiler was throwing a free(): invalid next size(normal) error. I thought of 2 explanations for this (please enlighten me if anyone knows more): 1.) This resulted in some random memory being assigned to it but since this wasn't accessible it was freeing up all the other heap memory just trying to find this int. 2.) The memory required by it was practically infinite for a program and to assign this it was freeing up all other memory.
我遇到了类似的错误。这是一个匆忙完成的菜鸟错误。没有声明大小 int a[] 然后尝试访问它的整数数组。如果 C++ 编译器在 main 中，它应该很容易捕捉到这样的错误。然而，由于这个特定的 int 数组是在一个对象内声明的，它与我的对象同时创建（正在创建许多对象）并且编译器抛出一个 free(): invalid next size(normal) 错误。我想到了 2 种解释（如果有人知道更多，请赐教）：1.）这导致分配了一些随机内存，但由于无法访问它，它正在释放所有其他堆内存只是试图找到这个整数。2.) 它所需要的内存对于一个程序来说实际上是无限的，分配它是释放所有其他内存。
A simple:
一个简单的：
int* a;
class foo{
foo(){
for(i=0;i<n;i++)
a=new int[i];
}
Solved the problem. But it did take a lot of time trying to debug this because the compiler could not "really" find the error.
解决了问题。但是尝试调试它确实花费了很多时间，因为编译器无法“真正”找到错误。
