By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,180 Members | 1,016 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,180 IT Pros & Developers. It's quick & easy.

fwrite() and free() bug

P: n/a
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(&bufLen); /* '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.
Nov 14 '05 #1
Share this Question
Share on Google+
15 Replies


P: n/a
"Suraj Kurapati" <sk******@ucsc.edu> wrote in message
news:40abe3dc@darkstar...
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(&bufLen); /* '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
Nov 14 '05 #2

P: n/a
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.
Nov 14 '05 #3

P: n/a
In article <40abeaec@darkstar>, 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
Nov 14 '05 #4

P: n/a
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(&bufLen); /* '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
Nov 14 '05 #5

P: n/a
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
Nov 14 '05 #6

P: n/a
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).

Nov 14 '05 #7

P: n/a

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

Nov 14 '05 #8

P: n/a
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
Nov 14 '05 #9

P: n/a
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(&bufLen); /* '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.
Nov 14 '05 #10

P: n/a

"Suraj Kurapati" <sk******@ucsc.edu> wrote in message
news:40abeaec@darkstar...
Mabden wrote:
I conjecture that buf has no space allocated to it.


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

Thanks.


Actually, it is not.

You're welcome.
Nov 14 '05 #11

P: n/a

"Stephen L." <sd*********@cast-com.net> wrote in message
news:40***************@cast-com.net...
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(&bufLen); /* '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,

I thought I said that.
;-)

--
Mabden
Nov 14 '05 #12

P: n/a
Suraj Kurapati wrote:
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 */

Was buff allocated dynamically / Was it a static variable.

like - if you had done -

char buff[512];

free(buff);

It does not make sense !!

--
Karthik.
Humans please 'removeme_' for my real email.
Nov 14 '05 #13

P: n/a
On Wed, 19 May 2004 15:44:10 -0700, Suraj Kurapati <sk******@ucsc.edu>
wrote:
buf = recv_data(&bufLen); /* 'bufLen' has the length of 'buf' */

if(buf != NULL)
You aren't checking for when buf is a valid pointer, but bufLen is <= 0.

if(fwrite(buf, sizeof(char), bufLen, fd) <= 0)


Your checking for an error return from fwrite is incorrect. Try:

if (fwrite(buf, 1, bufLen, fd) != bufLen)

7.19.8.2

Returns
3 The fwrite function returns the number of elements successfully written,
which will be less than nmemb only if a write error is encountered. If
size or nmemb is zero, fwrite returns zero and the state of the stream
remains unchanged.
--
#include <standard.disclaimer>
_
Kevin D Quitt USA 91387-4454 96.37% of all statistics are made up
Per the FCA, this address may not be added to any commercial mail list
Nov 14 '05 #14

P: n/a
Suraj Kurapati <sk******@ucsc.edu> wrote in message:

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(&bufLen); /* '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.


Probably there is a bug in recv_data(). Try replacing it with this and
see if your crash still occurs:

void *recv_data(int *len)
{
return calloc(*len = 512, 1);
}
Nov 14 '05 #15

P: n/a
Old Wolf wrote:
Probably there is a bug in recv_data(). Try replacing it with this and
see if your crash still occurs:

void *recv_data(int *len)
{
return calloc(*len = 512, 1);
}


Yeah there was a allocation bug in my recv_data() func.
I feel so satisfied now that it's fixed.

Thanks everyone for your help.
Nov 14 '05 #16

This discussion thread is closed

Replies have been disabled for this discussion.