Erro: free (): próximo tamanho inválido (rápido):

Qual é esse erro estranho que estou recebendo? Estou compilando o C ++ usando g ++ no Ubuntu 10.10. Ele aparece aleatoriamente quando eu executo o executável (talvez 2 vezes em 8 horas, com 10 compilações por hora). No entanto, se eu fizer limpo e recompilar, ele desaparecerá a maior parte do tempo.

*** 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 

Isso significa que você tem um erro de memory. Você pode estar tentando free um ponteiro que não foi alocado pelo malloc (ou delete um object que não tenha sido criado pelo new ) ou você pode estar tentando free / delete um object assim mais de uma vez. Você pode estar transbordando um buffer ou gravando de outra forma na memory para a qual você não deveria estar gravando, causando corrupção de heap.

Qualquer número de erros de programação pode causar esse problema. Você precisa usar um depurador, obter um backtrace e ver o que seu programa está fazendo quando o erro ocorre. Se isso falhar e você determinar que corrompeu o heap em algum ponto anterior no tempo, pode estar sofrendo uma debugging dolorosa (pode não ser muito doloroso se o projeto for pequeno o suficiente para que você possa resolvê-lo peça por peça).

Eu encontrei o mesmo problema, mesmo que eu não tenha feito nenhuma alocação de memory dinâmica no meu programa, mas eu estava acessando o índice de um vetor sem alocar memory para ele. Portanto, se o mesmo caso, aloque melhor a memory usando resize() e acesse os elementos do vetor.

Precisamos do código, mas isso geralmente aparece quando você tenta free() memory de um ponteiro que não está alocado. Isso geralmente acontece quando você está liberando o dobro.

Eu encontrei um erro semelhante. Foi um erro noob feito com pressa. Integer array sem declarar size int a [] tentando acessá-lo. O compilador C ++ deveria ter detectado um erro desse tipo facilmente se estivesse no main. No entanto, como esse array int particular foi declarado dentro de um object, ele estava sendo criado ao mesmo tempo que meu object (muitos objects estavam sendo criados) e o compilador estava lançando um erro free (): next size (normal) inválido. Eu pensei em 2 explicações para isso (por favor, me ilumine se alguém souber mais): 1.) Isso resultou em alguma memory aleatória sendo atribuída a ele, mas como isso não era acessível, liberava todas as outras memorys que estavam tentando encontrar este int. 2.) A memory requerida por ela era praticamente infinita para um programa e para designar isto estava liberando todas as outras memorys.

Um simples:

  int* a; class foo{ foo(){ for(i=0;i 

Resolveu o problema. Mas demorou muito tempo tentando depurar isso porque o compilador não conseguiu "realmente" encontrar o erro.

Se você estiver tentando alocar espaço para uma matriz de pointers, como

 char** my_array_of_strings; // or some array of pointers such as int** or even void** 

então você precisará considerar o tamanho da palavra (8 bytes em um sistema de 64 bits, 4 bytes em um sistema de 32 bits) ao alocar espaço para n pointers. O tamanho de um ponteiro é o mesmo do tamanho da sua palavra.

Então, enquanto você pode querer alocar espaço para n pointers, você realmente precisará de n vezes 8 ou 4 (para sistemas de 64 ou 32 bits, respectivamente)

Para evitar sobrecarregar sua memory alocada para n elementos de 8 bytes:

 my_array_of_strings = (char**) malloc( n * 8 ); // for 64-bit systems my_array_of_strings = (char**) malloc( n * 4 ); // for 32-bit systems 

Isso retornará um bloco de n pointers, cada um consistindo de 8 bytes (ou 4 bytes se você estiver usando um sistema de 32 bits)

Tenho notado que o Linux permitirá que você use todos os pointers n quando você não tiver compensado o tamanho da palavra, mas quando você tenta liberar essa memory percebe seu erro e isso dá um erro bastante desagradável. E é ruim, quando você sobrecarrega a memory alocada, muitos problemas de segurança ficam à espera.

Eu encontrei uma situação em que o código estava contornando a API do STL e escrevendo para o array de maneira insegura quando alguém o redimensionava. Adicionando a afirmação aqui pegou:

 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() ); }