Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > fwrite() and free() bug

Reply
Thread Tools

fwrite() and free() bug

 
 
Suraj Kurapati
Guest
Posts: n/a
 
      05-19-2004
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.
 
Reply With Quote
 
 
 
 
Mabden
Guest
Posts: n/a
 
      05-19-2004
"Suraj Kurapati" <(E-Mail Removed)> 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


 
Reply With Quote
 
 
 
 
Suraj Kurapati
Guest
Posts: n/a
 
      05-19-2004
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.
 
Reply With Quote
 
Richard Tobin
Guest
Posts: n/a
 
      05-19-2004
In article <40abeaec@darkstar>, Suraj Kurapati <(E-Mail Removed)> 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
 
Reply With Quote
 
Default User
Guest
Posts: n/a
 
      05-19-2004
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
 
Reply With Quote
 
Stephen L.
Guest
Posts: n/a
 
      05-19-2004
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
 
Reply With Quote
 
Suraj Kurapati
Guest
Posts: n/a
 
      05-20-2004
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).

 
Reply With Quote
 
Arthur J. O'Dwyer
Guest
Posts: n/a
 
      05-20-2004

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

 
Reply With Quote
 
Stephen L.
Guest
Posts: n/a
 
      05-20-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.
>
> 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
 
Reply With Quote
 
J. J. Farrell
Guest
Posts: n/a
 
      05-20-2004
Suraj Kurapati <(E-Mail Removed)> 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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
*bug* *bug* *bug* David Raleigh Arnold Firefox 12 04-02-2007 03:13 AM
ASP.NET Login control bug or SQL 2005 bug? RedEye ASP .Net 2 12-13-2005 10:57 AM
Re: BUG? OR NOT A BUG? John ASP .Net 2 09-21-2005 10:31 AM
rdoc bug (and rdoc bug tracker site is down) Brian Schröder Ruby 5 09-18-2004 02:08 PM
how to report bug to g++ ? got a bug and fixed up source code DarkSpy C++ 4 06-27-2003 09:05 AM



Advertisments