fwrite() and free() bug

S

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(&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.
 
M

Mabden

Suraj Kurapati said:
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.
Click to expand...

I conjecture that buf has no space allocated to it.
 
S

Suraj Kurapati

Mabden said:
I conjecture that buf has no space allocated to it.
Click to expand...

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.
 
R

Richard Tobin

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

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
 
D

Default User

Suraj said:
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.
Click to expand...
/* ... some initialization code */
Click to expand...


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
 
S

Stephen L.

Suraj said:
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.
Click to expand...

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
 
S

Suraj Kurapati

Richard said:
fwrite() itself may well call malloc(), which would explain why the
error only shows up when you call it.
Click to expand...

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).
 
A

Arthur J. O'Dwyer

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.
Click to expand...

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).
Click to expand...

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
 
S

Stephen L.

Suraj said:
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).
Click to expand...

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. J. Farrell

Suraj Kurapati said:
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?
Click to expand...

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.
 
M

Mabden

Stephen L. said:
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,
Click to expand...


I thought I said that.
;-)
 
K

Karthik

Suraj said:
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 */
Click to expand...
Was buff allocated dynamically / Was it a static variable.

like - if you had done -

char buff[512];

free(buff);

It does not make sense !!
 
K

Kevin D. Quitt

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

if(buf != NULL)
Click to expand...

You aren't checking for when buf is a valid pointer, but bufLen is <= 0.

if(fwrite(buf, sizeof(char), bufLen, fd) <= 0)
Click to expand...

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.
 
O

Old Wolf

Suraj Kurapati said:
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.
Click to expand...

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

Suraj Kurapati

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);
}
Click to expand...

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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

error 28
inline and static functions 3
epoll networking code review 4
Do I need a FIFO queue? 8
write error 13
Getting a "Segmentation Fault" when running on Linux 17
I dont know how to modify this. Can someone help. 0
facing segmentation fault when i tried to free dynamic memory... 4

Members online

No members online now.
Total: 2,764 (members: 0, guests: 2,764)
Robots: 195

Forum statistics

Threads
474,142
Messages
2,570,819
Members
47,367
Latest member
mahdiharooniir

Latest Threads

Top