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?

TIA!
Lei

Well, it could be that you have another thread trying to read the data after you've free it.

The only other thing I can think of is that you are overrunning the buffer or a buffer somewhere. If you do, sometimes the results are very weird.

I always do an "if (ptr) free(ptr)". I think its a good habbit to get into.

Doesn't always work though.

Btw, just because the pointer contains an address doesn't mean it valid. Try setting your pointers to NULL before you use them. Also, try taking the assignment out of the if statement:

ptr = malloc();
if (ptr == NULL)
{
}
etc...


Not:

if ((ptr = malloc())==NULL)
{
}
etc...


My teacher said this was a bad thing to do. Even if he is wrong, and there is nothing wrong with the 2nd statement, it still looks messy. A few extra lines wont hurt anyone!

"Btw, just because the pointer contains an address doesn't mean it valid. Try setting your pointers to NULL before you use them."

Well, this I agree, but as I've mentioned, the address is the same with what it is initially allocated, and this code isn't so wrong because it works with small files.

Thanks!
Lei

just a stupid brute force guess - how about calloc? does it change the outcome?
would be interesting to see what operations in_buffer is exposed to inside that loop.

you're overflowing a buffer. use valgrind.

No, calloc won't help

I am trying with Valgrind.

Thanks!
Lei

What is the difference between stack buffer overflow and heap buffer overflow? Which case I am most likely to be in now?

Thanks a lot!
Lei

malloc always allocates memory from heap. so your problem lies there. I guess you should post your code so that others can better understand the problem.

Well, I'd like to, but unfortunately that piece of code is not written by me and I don't have the right to post it I am only authorized to use it as a function in my project. Also the code is not a trivial one and is a bit long.

Thanks for your suggestions, anyway. I'll try to debug with Valgrind first and see what I can do with it.

Lei

When you successfuly call malloc() and return the value for a pointer, most malloc implmentations store the length of the buffer allocated at the physical address ptr - 1; This group of bytes is called a descriptor - in Windows it's BSTR - (on 32 bit machines: 4 byte longword of buffer length, 4 byte longword for the pointer to the start of the buffer).

So, if you execute ptr++ -- or something writes a value into the memory at the address just before the physical address of ptr, you break free(), because it tries to mess with a buffer of the wrong size.

That's sound reasonable, but I did print out 4 bytes before the physical address of ptr, after malloc and before free, and they are the same.

Thanks,
Lei

There are other data structures involved - I simplified it.
You can always download linux source and find out exactly what malloc and free are doing.

Thanks folks, I fixed the problem, finally.

It is because when I malloc memory for the buffer, the size is smaller than actually needed, my estimation of buffer length is not right So the guess of buffer overflow is correct! And this is not directly related with file size.

Valgrind is really cool....

Cheers,
Lei