fwrite() and free() bug

[Suraj Kurapati]

Hello,

I'm having a rather strange bug with this code: for certain values of 'buf',
a segmentation fault occurs when 'free(buf)' is followed by an 'fwrite()'.
In the program output, there is no error reported by 'perror()' and the
file is written correctly.

/* returns NULL upon failure, or a calloc()ed data upon success */
char* recv_data(int *bytes_read);

int main(int argc, char** argv)
{
char *buf;
int bufLen;
FILE *fd;

/* ... some initialization code */

buf = recv_data(&bufL en); /* 'bufLen' has the length of 'buf' */

if(buf != NULL)
{
if(fwrite(buf, sizeof(char), bufLen, fd) <= 0)
perror("fwrite" );

free(buf); /* segmentation fault occurs here */
buf = NULL;
}

return 0;
}

There is no crash when I remove the call to 'fwrite()', regardless of the
value of 'buf'. Thus I conjecture that 'fwrite()' is the culprit here.

Any ideas?

Thanks.

[Mabden]

"Suraj Kurapati" <sk******@ucsc. edu> wrote in message
news:40abe3dc@d arkstar...

Hello,

I'm having a rather strange bug with this code: for certain values of 'buf', a segmentation fault occurs when 'free(buf)' is followed by an 'fwrite()'.
In the program output, there is no error reported by 'perror()' and the
file is written correctly.

/* returns NULL upon failure, or a calloc()ed data upon success */
char* recv_data(int *bytes_read);

int main(int argc, char** argv)
{
char *buf;
int bufLen;
FILE *fd;

/* ... some initialization code */

buf = recv_data(&bufL en); /* 'bufLen' has the length of 'buf' */
if(buf != NULL)
{
if(fwrite(buf, sizeof(char), bufLen, fd) <= 0)
perror("fwrite" );

free(buf); /* segmentation fault occurs here */
buf = NULL;
}

return 0;
}

There is no crash when I remove the call to 'fwrite()', regardless of the
value of 'buf'. Thus I conjecture that 'fwrite()' is the culprit here.

I conjecture that buf has no space allocated to it.

--
Mabden

[Suraj Kurapati]

Mabden wrote:

I conjecture that buf has no space allocated to it.

Actually, this condition is checked by the statement "if(buf != NULL) {}".

Consider this:

if(buf != NULL)
{
free(buf); /* works fine */
}

As opposed to this:

if(buf != NULL)
{
if(fwrite(buf, sizeof(char), bufLen, fd) <= 0)
perror("fwrite" );

free(buf); /* segmentation fault occurs here */
}

Thanks.

[Richard Tobin]

In article <40abeaec@darks tar>, Suraj Kurapati <sk******@ucsc. edu> wrote:

Mabden wrote: Actually, this condition is checked by the statement "if(buf != NULL) {}".

That doesn't check that your function really allocated the space
correctly, of course.

There's clearly something going on that's not shown in the code you've
posted. Probably a malloc()/free() error somewhere else. I suggest
linking with a debugging version of malloc().

fwrite() itself may well call malloc(), which would explain why the
error only shows up when you call it.

-- Richard

[Stephen L.]

Suraj Kurapati wrote:

Hello,

I'm having a rather strange bug with this code: for certain values of 'buf',
a segmentation fault occurs when 'free(buf)' is followed by an 'fwrite()'.
In the program output, there is no error reported by 'perror()' and the
file is written correctly.

/* returns NULL upon failure, or a calloc()ed data upon success */
char* recv_data(int *bytes_read);

int main(int argc, char** argv)
{
char *buf;
int bufLen;
FILE *fd;

/* ... some initialization code */

buf = recv_data(&bufL en); /* 'bufLen' has the length of 'buf' */

if(buf != NULL)
{
if(fwrite(buf, sizeof(char), bufLen, fd) <= 0)
perror("fwrite" );

free(buf); /* segmentation fault occurs here */
buf = NULL;
}

return 0;
}

There is no crash when I remove the call to 'fwrite()', regardless of the
value of 'buf'. Thus I conjecture that 'fwrite()' is the culprit here.

Any ideas?

Thanks.

I _really_ suspect your `recv_data()' function.

Since you say that only certain values of `buf'
cause this leads me to believe that you may
possibly be over-running `buf'. Consider
that, in general, `calloc()' will allocate
more space than is actually requested by
some small power of 2 (16, 32 bytes, etc.)
usually for efficiency of the algorithm/hardware, etc.

Lets assume your library allocates memory
blocks in multiples of 16 bytes.

If you request 15 bytes, you'll get 16 - I
think you see where I'm going with this.
If you're overwriting `buf' by a single
byte, you won't see a problem since it's
still within the buffer's limits.

But, on that occasion where you request 16,
and actually get exactly 16 (but actually need 17),
then that extra byte is corrupting the heap,
and your next call to `free()' seg faults.

That's my theory, and I'm sticking to it...

If `recv_data()' is small enough to post,
I'd suggest that. Since `fwrite()' is used
in billions of places, I _really_ doubt
there's a problem with `fwrite()'.

HTH,
Stephen

[Default User]

Suraj Kurapati wrote:

Hello,

I'm having a rather strange bug with this code: for certain values of 'buf',
a segmentation fault occurs when 'free(buf)' is followed by an 'fwrite()'.
In the program output, there is no error reported by 'perror()' and the
file is written correctly.
/* ... some initialization code */

Please post COMPLETE programs. We have no idea what went on in this
section, especially whether that included allocating sufficient space to
your buffer. The symptom you describe is that of corrupted memory, such
as overrunning the bounds of a dynamically allocated array.

Brian Rodenborn

[Suraj Kurapati]

Richard Tobin wrote:

fwrite() itself may well call malloc(), which would explain why the
error only shows up when you call it.

Thanks, that did the trick.

By replacing the calls to fopen()/fwrite()/fclose() with
open()/write()/close(), the call to 'free(buf)' no longer crashes.

The latter set of system calls operate on an int, rather than a dynamically
allocated FILE struct (which was the source of the trouble).

[Arthur J. O'Dwyer]

On Wed, 19 May 2004, Suraj Kurapati wrote:

Richard Tobin wrote:

fwrite() itself may well call malloc(), which would explain why the
error only shows up when you call it.
Thanks, that did the trick.

By replacing the calls to fopen()/fwrite()/fclose() with
open()/write()/close(), the call to 'free(buf)' no longer crashes.

open(), write(), and close() are none of them standard C functions.
You may know this already, of course, but you are sacrificing portability
by using them.
The latter set of system calls operate on an int, rather than a dynamically
allocated FILE struct (which was the source of the trouble).

Wouldn't it be more responsible to fix *YOUR* mistake now, rather
than hacking around it without fixing it? If you really can't find
the source of the error, post some code and I'm sure the experts here
will be glad to show you where you went wrong.

-Arthur

[Stephen L.]

Suraj Kurapati wrote:

Richard Tobin wrote:

fwrite() itself may well call malloc(), which would explain why the
error only shows up when you call it.

Thanks, that did the trick.

By replacing the calls to fopen()/fwrite()/fclose() with
open()/write()/close(), the call to 'free(buf)' no longer crashes.

The latter set of system calls operate on an int, rather than a dynamically
allocated FILE struct (which was the source of the trouble).

I think you're going to have a difficult task convincing
readers of comp.lang.c that the fopen()/fwrite()/fclose()
family of I/O functions are the culprit...
Stephen

[J. J. Farrell]

Suraj Kurapati <sk******@ucsc. edu> wrote in message news:<40abe3dc@ darkstar>...

I'm having a rather strange bug with this code: for certain values of 'buf',
a segmentation fault occurs when 'free(buf)' is followed by an 'fwrite()'.
In the program output, there is no error reported by 'perror()' and the
file is written correctly.

/* returns NULL upon failure, or a calloc()ed data upon success */
char* recv_data(int *bytes_read);

int main(int argc, char** argv)
{
char *buf;
int bufLen;
FILE *fd;

/* ... some initialization code */

buf = recv_data(&bufL en); /* 'bufLen' has the length of 'buf' */

if(buf != NULL)
{
if(fwrite(buf, sizeof(char), bufLen, fd) <= 0)
perror("fwrite" );

free(buf); /* segmentation fault occurs here */
buf = NULL;
}

return 0;
}

There is no crash when I remove the call to 'fwrite()', regardless of the
value of 'buf'. Thus I conjecture that 'fwrite()' is the culprit here.

Any ideas?

You probably have a bug in the code you haven't shown, either corrupting
buf or overrunning the end of the buffer that buf points to.