Segmentation fault from free()

Hi friends,

I am writing a c code and have been bugged by this segmentation fault for a while.

What I did is simply like:

-----------------------------------------------------------------------------------------------------
.........
unsigned long blocksize = 2048;
char *in_buffer
char *out_buffer;
if(( in_buffer= malloc(blocksize)) == NULL)
{
fprintf(stderr, "*** Can't malloc(%ld) forbuffer.\n",blocksize); return NULL;
}

if(( out_buffer= malloc(2*blocksize)) == NULL)
{
fprintf(stderr, "*** Can't malloc(%ld) forbuffer.\n",blocksize); free(in_buffer);
return NULL;
}

loop: until all the data are read from file
{
//read a block of data from a file to in_buffer
// do some data processing with in_buffer
//write the result to out_buffer
//memcpy out_buffer to list
}

free(in_buffer);
free(out_buffer);

return list;
......
-----------------------------------------------------------------------------------------------------------------

I've debugged with gdb to see where the segmentation fault happens, it is at free(in_buffer).
I've verified that the value for in_buffer after malloc() and before free() is the same. Or in other words, in_buffer is a valid pointer allocated by malloc.

And the SF only happens when the file is large, although block size could be small.
Means that for both small (2KB) and large(5MB) files, block size are the same. However, only large files could cause SF.

Could anyone please point me out what could possibly be the reason?
BTW, pls cc me when you reply, since I am not able to receive emails from this list. Thanks a lot!

TIA!
Lei

Cannot say something definitely with incomplete source code.

The bug is not necessarily in the malloc/free pair of this construct. Likely you destroyed the heap structure in earlier memory allocation/deallocation operations (e.g. during list processing). You may want to check your program with a memory debugger, e.g. valgrind for i386 platform.

Robert

Robert Schiele			Tel.: +49-621-181-2517
Dipl.-Wirtsch.informatiker	mailto:[email protected]

Do you mean that something 'free' needs has been destroyed? Why this wouldn't happen with small files?

THe memory debugger idea is definitely a good one, I'll try that.

Thanks a lot!
Lei

Free memory has is managed by the heap data structure. If you free an address twice or free an adress that was never allocated, the data structure will get corrupted. Often this does occur silently, but in a later state a malloc or free call with this corrupted data structure might crash your application.

I don't know your application and thus I am not even sure that this is the source of your problem. This was just a wild guess as it is a typical error in such situations.

Robert

Robert Schiele			Tel.: +49-621-181-2517
Dipl.-Wirtsch.informatiker	mailto:[email protected]

As already said, not much to ay w/o the full source. However, you have allocated a 4Kb buffer. possibly
you are reading beyond that limit into some memory space
not belonging to your program and when you try to free it, you get a segfault. A wild guess, but is possible since you say this is happening only for large files.

regards,
Joy.M.Monteiro

Are you writting exactly 2048 chars to in_buffer?? Or are you writting 2047??
If you want to write 2048 chars into in_buffer, you have to malloc 2049 bytes, to store the '\0' char.
I know it seems a little stupid observation, but sometimes we let this stupid errors happen.

Mariano Moreyra

-----Mensaje original-----
De: [email protected] [mailto:[email protected]]En nombre de Lei Yang Enviado el: Martes, 24 de Agosto de 2004 17:34
Para: [email protected]; [email protected]
CC: Lei Yang
Asunto: Segmentation fault from free()

Hi friends,

I am writing a c code and have been bugged by this segmentation fault for a while.

What I did is simply like:

----------------------------------------------------------------------------
-------------------------
.........
unsigned long blocksize = 2048;
char *in_buffer
char *out_buffer;
if(( in_buffer= malloc(blocksize)) == NULL)
{
fprintf(stderr, "*** Can't malloc(%ld) forbuffer.\n",blocksize); return NULL;
}

if(( out_buffer= malloc(2*blocksize)) == NULL)
{
fprintf(stderr, "*** Can't malloc(%ld) forbuffer.\n",blocksize); free(in_buffer);
return NULL;
}

loop: until all the data are read from file
{
//read a block of data from a file to in_buffer
// do some data processing with in_buffer
//write the result to out_buffer
//memcpy out_buffer to list
}

free(in_buffer);
free(out_buffer);

return list;
......
----------------------------------------------------------------------------
-------------------------------------

I've debugged with gdb to see where the segmentation fault happens, it is at free(in_buffer).
I've verified that the value for in_buffer after malloc() and before free() is the same. Or in other words, in_buffer is a valid pointer allocated by malloc.

And the SF only happens when the file is large, although block size could be small.
Means that for both small (2KB) and large(5MB) files, block size are the same. However, only large files could cause SF.

Could anyone please point me out what could possibly be the reason? BTW, pls cc me when you reply, since I am not able to receive emails from this list. Thanks a lot!

TIA!
Lei
-
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

_______________________________________

Importante

El contenido del presente mensaje y el de sus adjuntos, es privado, confidencial y de uso exclusivo de los destinatarios a los cuales está dirigído, pudiendo contener información legalmente protegida.Queda prohibida la revisión, divulgación, publicación, modificación, copia, distribución o acción en relación con esta información, por personas o entidades distintas al destinatario.

Las opiniones contenidas son exclusivas de su autor y no representan ni necesariamente pueden coincidir con las de la entidad.

La transmisión de e-mails no garantiza que el correo electrónico sea seguro o libre de error. En consecuencia, no manifestamos que la información sea completa o precisa. Toda información está sujeta a alterarse sin previo aviso.

Si Ud. recibió este mensaje por error, por favor reenvíelo al remitente y destruya las copias de papel o grabadas en cualquier medio magnético, que pueda haber realizado.

Muchas Gracias.