Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #8327 > unrolled thread

Fread problem

Back to article view | Back to comp.lang.c

Contents

  Fread problem Jack <spamtrap@trashcan.invalid> - 2011-07-15 20:56 +0000
    Re: Fread problem Ian Collins <ian-news@hotmail.com> - 2011-07-16 09:05 +1200
      Re: Fread problem Noob <root@127.0.0.1> - 2011-07-19 13:41 +0200
    Re: Fread problem John Gordon <gordon@panix.com> - 2011-07-15 21:43 +0000
      Re: Fread problem Jack <spamtrap@trashcan.invalid> - 2011-07-16 09:22 +0000
        Re: Fread problem Dr Nick <3-nospam@temporary-address.org.uk> - 2011-07-16 10:25 +0100
          Re: Fread problem Jack <spamtrap@trashcan.invalid> - 2011-07-16 20:23 +0000
            Re: Fread problem Ian Collins <ian-news@hotmail.com> - 2011-07-17 08:37 +1200
            Re: Fread problem John Gordon <gordon@panix.com> - 2011-07-16 20:46 +0000
              Re: Fread problem James Kuyper <jameskuyper@verizon.net> - 2011-07-16 18:29 -0400
                Re: Fread problem John Gordon <gordon@panix.com> - 2011-07-16 23:14 +0000
            Re: Fread problem Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-07-16 16:55 -0400
              Re: Fread problem blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-07-19 17:17 +0000
                [OT] Re: Fread problem Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-07-19 20:11 -0400
                  Re: [OT] Re: Fread problem Seebs <usenet-nospam@seebs.net> - 2011-07-20 02:27 +0000
            Re: Fread problem Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-07-16 14:57 -0600
              Re: Fread problem Jack <spamtrap@trashcan.invalid> - 2011-07-17 20:45 +0000
                Re: Fread problem Ian Collins <ian-news@hotmail.com> - 2011-07-18 08:50 +1200
                Re: Fread problem James Kuyper <jameskuyper@verizon.net> - 2011-07-17 17:06 -0400
                  Re: Fread problem Ian Collins <ian-news@hotmail.com> - 2011-07-18 09:09 +1200
                  Re: Fread problem Hans Vlems <hvlems@freenet.de> - 2011-07-18 13:01 -0700
                Re: Fread problem Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-07-17 16:06 -0600
                Re: Fread problem Geoff <geoff@invalid.invalid> - 2011-07-17 17:56 -0700
                  Re: Fread problem Seebs <usenet-nospam@seebs.net> - 2011-07-18 04:08 +0000
                    Re: Fread problem Geoff <geoff@invalid.invalid> - 2011-07-17 22:08 -0700
                  Re: Fread problem Jack <spamtrap@trashcan.invalid> - 2011-07-18 20:20 +0000
                    Re: Fread problem Ian Collins <ian-news@hotmail.com> - 2011-07-19 08:50 +1200
                    Re: Fread problem Cat 22 <cat22@invalid.org> - 2011-07-18 18:34 -0700
                    Re: Fread problem James Kuyper <jameskuyper@verizon.net> - 2011-07-19 07:19 -0400
                    Re: Fread problem Stephen Sprunk <stephen@sprunk.org> - 2011-07-19 09:31 -0500
                Re: Fread problem Todd Carnes <toddcarnes@gmail.com> - 2011-07-18 04:23 +0000
                Re: Fread problem Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-07-18 01:15 -0700
                Re: Fread problem Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-07-18 07:22 -0400
                  Re: Fread problem Kenneth Brody <kenbrody@spamcop.net> - 2011-07-18 13:56 -0400
                Re: Fread problem Kenneth Brody <kenbrody@spamcop.net> - 2011-07-18 13:49 -0400
                  Re: Fread problem Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-07-18 20:31 -0400
                    Re: Fread problem Squeamizh <squeamz@hotmail.com> - 2011-07-18 21:11 -0700
                Re: Fread problem blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-07-19 17:19 +0000
                  Re: Fread problem Kenneth Brody <kenbrody@spamcop.net> - 2011-07-19 14:18 -0400
                    Re: Fread problem pete <pfiland@mindspring.com> - 2011-07-19 15:19 -0400
                    Re: Fread problem blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-07-19 21:33 +0000
            Re: Fread problem Geoff <geoff@invalid.invalid> - 2011-07-16 14:27 -0700
              Re: Fread problem John Gordon <gordon@panix.com> - 2011-07-16 22:22 +0000
            Re: Fread problem "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-07-16 23:28 -0700
            Re: Fread problem "J. J. Farrell" <jjf@bcs.org.uk> - 2011-07-18 04:58 +0100
            Re: Fread problem Keith Thompson <kst-u@mib.org> - 2011-07-18 08:53 -0700
              Re: Fread problem Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-07-18 18:07 +0100
                Re: Fread problem Keith Thompson <kst-u@mib.org> - 2011-07-18 12:50 -0700
              Re: Fread problem Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-07-18 12:18 -0600
              Re: Fread problem John Gordon <gordon@panix.com> - 2011-07-18 20:18 +0000
                Re: Fread problem Keith Thompson <kst-u@mib.org> - 2011-07-18 13:28 -0700
                  Re: Fread problem Lew Pitcher <lpitcher@teksavvy.com> - 2011-07-18 16:55 -0400
                Re: Fread problem Anders Wegge Keller <wegge@wegge.dk> - 2011-07-18 22:51 +0200
              Re: Fread problem blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-07-19 17:21 +0000
            Re: Fread problem Kenneth Brody <kenbrody@spamcop.net> - 2011-07-18 13:44 -0400
        Re: Fread problem Ian Collins <ian-news@hotmail.com> - 2011-07-16 21:39 +1200
        Re: Fread problem Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-07-16 12:18 -0600
        Re: Fread problem John Gordon <gordon@panix.com> - 2011-07-16 19:36 +0000

Page 1 of 3  [1] 2 3  Next page →

#8327 — Fread problem

Hi,

I got a strange problem with Fread:

It crashes my program from time to time, in one of its internal memcpy 
calls.

I managed to bypass this bug one time by creating a bigger file buffer, 
but it's just a patch...

Does anyone knows anything about it?
Is there a clean way to reset the file buffers?
Can this be compiler dependent (gcc 4.1) - maybe a compiler bug?

Thanks for any help

[toc] | [next] | [standalone]

#8328

On 07/16/11 08:56 AM, Jack wrote:
> Hi,
>
> I got a strange problem with Fread:
>
> It crashes my program from time to time, in one of its internal memcpy
> calls.

Assuming it is fread(), it is very unlikely the function is the cause of 
the problem.  The much more likely cause is something else in your 
program stomping on the bugger space.

Run the program with an bounds checker (such is Valgrind in Linux).


-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#8478

Ian Collins wrote:

> The much more likely cause is something else in your
> program stomping on the bugger space.

Stomping on the bugger space is a nasty bug!

[toc] | [prev] | [next] | [standalone]

#8329

In <ivq9i7$841$1@speranza.aioe.org> Jack <spamtrap@trashcan.invalid> writes:

> I got a strange problem with Fread:

> It crashes my program from time to time, in one of its internal memcpy 
> calls.

When things like this happen it is nearly always because of a memory
corruption bug elsewhere in your program, not because of a bug in a
library function like fread().

C is, unfortunately, a fragile language.  If you copy more to a buffer
than it can hold, or call free() on a bad value, or call free() twice on
the same value, you've just corrupted the memory space of your program and
anything can happen from that point onward, including crashes in library
functions such as fread().

If your program is a simple one, go over it again and try to identify any
areas where you might have committed the above errors.  If it's a complex
program, you might use a memory analyzer such as efence or valgrind.

-- 
John Gordon                   A is for Amy, who fell down the stairs
gordon@panix.com              B is for Basil, assaulted by bears
                                -- Edward Gorey, "The Gashlycrumb Tinies"

[toc] | [prev] | [next] | [standalone]

#8351

On Fri, 15 Jul 2011 21:43:53 +0000, John Gordon wrote:
> In <ivq9i7$841$1@speranza.aioe.org> Jack <spamtrap@trashcan.invalid>
> writes:
> 
>> I got a strange problem with Fread:
> 
>> It crashes my program from time to time, in one of its internal memcpy
>> calls.
> 
> When things like this happen it is nearly always because of a memory
> corruption bug elsewhere in your program, not because of a bug in a
> library function like fread().
> 
> C is, unfortunately, a fragile language.  If you copy more to a buffer
> than it can hold, or call free() on a bad value, or call free() twice on
> the same value, you've just corrupted the memory space of your program
> and anything can happen from that point onward, including crashes in
> library functions such as fread().
> 
> If your program is a simple one, go over it again and try to identify
> any areas where you might have committed the above errors.  If it's a
> complex program, you might use a memory analyzer such as efence or
> valgrind.

Yes...
Actually, I think it's a memory error somewhere that causes really
indirectly this bug.
But I find it strange that even a memory error makes a fread with proper
parameters ( I do check this ) fail.

I've heard somewhere one can play with the file buffer, so I tried it,
and put MY file buffer, with the Setbuff() function. And it didn't crash
anymore, but the read couldn't read all the files. Some bytes in the
middle were missing (I think it is when I resume the reading, after
having processed the first part)...

Last thing, this Fread occurs in a big source file... Created by lex / 
yacc.

The file is big, not easy to understand, so difficult to debug
: ( 

[toc] | [prev] | [next] | [standalone]

#8352

Jack <spamtrap@trashcan.invalid> writes:

> On Fri, 15 Jul 2011 21:43:53 +0000, John Gordon wrote:
>> In <ivq9i7$841$1@speranza.aioe.org> Jack <spamtrap@trashcan.invalid>
>> writes:
>> 
>>> I got a strange problem with Fread:
>> 
>>> It crashes my program from time to time, in one of its internal memcpy
>>> calls.
>> 
>> When things like this happen it is nearly always because of a memory
>> corruption bug elsewhere in your program, not because of a bug in a
>> library function like fread().
>> 
>> C is, unfortunately, a fragile language.  If you copy more to a buffer
>> than it can hold, or call free() on a bad value, or call free() twice on
>> the same value, you've just corrupted the memory space of your program
>> and anything can happen from that point onward, including crashes in
>> library functions such as fread().
>> 
>> If your program is a simple one, go over it again and try to identify
>> any areas where you might have committed the above errors.  If it's a
>> complex program, you might use a memory analyzer such as efence or
>> valgrind.
>
> Yes...
> Actually, I think it's a memory error somewhere that causes really
> indirectly this bug.
> But I find it strange that even a memory error makes a fread with proper
> parameters ( I do check this ) fail.

Somewhere the library and the operating system have to store things like
the details of the underlying file, the position in it etc.  When you
trample over memory you can overwrite this.

In particular, many systems get the buffers for the stdio streams from
the same memory pool as you get with malloc.  So do something wrong with
a block you've got from malloc and you can really mess the streams up.

And vice versa.  I once managed to get malloc to return "null" by
previously fclosing the same file pointer twice.

> I've heard somewhere one can play with the file buffer, so I tried it,
> and put MY file buffer, with the Setbuff() function. And it didn't crash
> anymore, but the read couldn't read all the files. Some bytes in the
> middle were missing (I think it is when I resume the reading, after
> having processed the first part)...

That's not incompatible with what I wrote above.
-- 
Online waterways route planner            | http://canalplan.eu
Plan trips, see photos, check facilities  | http://canalplan.org.uk

[toc] | [prev] | [next] | [standalone]

#8361

On Sat, 16 Jul 2011 10:25:41 +0100, Dr Nick wrote:

> Jack <spamtrap@trashcan.invalid> writes:
> 
>> On Fri, 15 Jul 2011 21:43:53 +0000, John Gordon wrote:
>>> In <ivq9i7$841$1@speranza.aioe.org> Jack <spamtrap@trashcan.invalid>
>>> writes:
>>> 
>>>> I got a strange problem with Fread:
>>> 
>>>> It crashes my program from time to time, in one of its internal
>>>> memcpy calls.
>>> 
>>> When things like this happen it is nearly always because of a memory
>>> corruption bug elsewhere in your program, not because of a bug in a
>>> library function like fread().
>>> 
>>> C is, unfortunately, a fragile language.  If you copy more to a buffer
>>> than it can hold, or call free() on a bad value, or call free() twice
>>> on the same value, you've just corrupted the memory space of your
>>> program and anything can happen from that point onward, including
>>> crashes in library functions such as fread().
>>> 
>>> If your program is a simple one, go over it again and try to identify
>>> any areas where you might have committed the above errors.  If it's a
>>> complex program, you might use a memory analyzer such as efence or
>>> valgrind.
>>
>> Yes...
>> Actually, I think it's a memory error somewhere that causes really
>> indirectly this bug.
>> But I find it strange that even a memory error makes a fread with
>> proper parameters ( I do check this ) fail.
> 
> Somewhere the library and the operating system have to store things like
> the details of the underlying file, the position in it etc.  When you
> trample over memory you can overwrite this.
> 
> In particular, many systems get the buffers for the stdio streams from
> the same memory pool as you get with malloc.  So do something wrong with
> a block you've got from malloc and you can really mess the streams up.
> 
> And vice versa.  I once managed to get malloc to return "null" by
> previously fclosing the same file pointer twice.
> 
>> I've heard somewhere one can play with the file buffer, so I tried it,
>> and put MY file buffer, with the Setbuff() function. And it didn't
>> crash anymore, but the read couldn't read all the files. Some bytes in
>> the middle were missing (I think it is when I resume the reading, after
>> having processed the first part)...
> 
> That's not incompatible with what I wrote above.

Thanks for your help. I think I've now found a solution.

After the file is first Fopen'd, I make a backup of the internal buffers.
fp=Fopen(...);
FILE fback;
memcpy(&fback,fp,sizeof(FILE));

then before the fread I restore this buffer,
memcpy(fp,&fback,sizeof(FILE));
Fread(...,fp);

Now there is no segmentation fault, job done.

[toc] | [prev] | [next] | [standalone]

#8362

On 07/17/11 08:23 AM, Jack wrote:

> Thanks for your help. I think I've now found a solution.

No, you have simply moved the problem elsewhere.

> After the file is first Fopen'd, I make a backup of the internal buffers.
> fp=Fopen(...);
> FILE fback;
> memcpy(&fback,fp,sizeof(FILE));
>
> then before the fread I restore this buffer,
> memcpy(fp,&fback,sizeof(FILE));
> Fread(...,fp);
>
> Now there is no segmentation fault, job done.

Until the bug you have yet to fix pops up in another random place.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#8363

In <ivss0p$ulb$1@speranza.aioe.org> Jack <spamtrap@trashcan.invalid> writes:

> Thanks for your help. I think I've now found a solution.

> After the file is first Fopen'd, I make a backup of the internal buffers.
> fp=Fopen(...);
> FILE fback;
> memcpy(&fback,fp,sizeof(FILE));

> then before the fread I restore this buffer,
> memcpy(fp,&fback,sizeof(FILE));
> Fread(...,fp);

> Now there is no segmentation fault, job done.

If that works, it's purely accidental and I wouldn't count on it.

Your code even has a bug: you're copying sizeof(FILE) bytes, but
fp is a pointer-to-FILE which is probably not the same size.


-- 
John Gordon                   A is for Amy, who fell down the stairs
gordon@panix.com              B is for Basil, assaulted by bears
                                -- Edward Gorey, "The Gashlycrumb Tinies"

[toc] | [prev] | [next] | [standalone]

#8369

On 07/16/2011 04:46 PM, John Gordon wrote:
> In <ivss0p$ulb$1@speranza.aioe.org> Jack <spamtrap@trashcan.invalid> writes:
> 
>> Thanks for your help. I think I've now found a solution.
> 
>> After the file is first Fopen'd, I make a backup of the internal buffers.
>> fp=Fopen(...);
>> FILE fback;
>> memcpy(&fback,fp,sizeof(FILE));
> 
>> then before the fread I restore this buffer,
>> memcpy(fp,&fback,sizeof(FILE));
>> Fread(...,fp);
> 
>> Now there is no segmentation fault, job done.
> 
> If that works, it's purely accidental and I wouldn't count on it.
> 
> Your code even has a bug: you're copying sizeof(FILE) bytes, but
> fp is a pointer-to-FILE which is probably not the same size.

If he wanted to copy the pointer, that would imply that he's got several
different errors, not just one. What you're thinking of would be written
as follows:

	FILE *fback;
	memcpy(&fback, &fp, sizeof fp);

Which is almost (but not quite) the same as the much simpler:

	FILE *fback = fp;

He's not copying fp, he's copying the FILE object that fp points at. It
can't be the correct solution to his problem, but it is done correctly.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#8370

In <ivt3ct$ukf$1@dont-email.me> James Kuyper <jameskuyper@verizon.net> writes:

> He's not copying fp, he's copying the FILE object that fp points at. It
> can't be the correct solution to his problem, but it is done correctly.

Why so it is.  My mistake.

-- 
John Gordon                   A is for Amy, who fell down the stairs
gordon@panix.com              B is for Basil, assaulted by bears
                                -- Edward Gorey, "The Gashlycrumb Tinies"

[toc] | [prev] | [next] | [standalone]

#8364

On 7/16/2011 4:23 PM, Jack wrote:
>[...]
> Thanks for your help. I think I've now found a solution.
>
> After the file is first Fopen'd, I make a backup of the internal buffers.
> fp=Fopen(...);
> FILE fback;
> memcpy(&fback,fp,sizeof(FILE));
>
> then before the fread I restore this buffer,
> memcpy(fp,&fback,sizeof(FILE));
> Fread(...,fp);
>
> Now there is no segmentation fault, job done.

     When your smoke alarm jolts you awake in the middle of the
night, do you fix the problem by stuffing cotton in your ears
and going back to sleep?

     When the BRAKE TROUBLE light on your car's dashboard refuses
to go out, do you put a piece of tape over it?

     When you're eating the leftovers from last week's sushi and
find that it smells and tastes rotten, do you pile on extra
wasabi to stun your taste buds?

     Do you wear Joo Janta Peril-Sensitive Sunglasses?

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#8490

In article <ivsttt$u4o$1@dont-email.me>,
Eric Sosman  <esosman@ieee-dot-org.invalid> wrote:
> On 7/16/2011 4:23 PM, Jack wrote:
> >[...]
> > Thanks for your help. I think I've now found a solution.
> >
> > After the file is first Fopen'd, I make a backup of the internal buffers.
> > fp=Fopen(...);
> > FILE fback;
> > memcpy(&fback,fp,sizeof(FILE));
> >
> > then before the fread I restore this buffer,
> > memcpy(fp,&fback,sizeof(FILE));
> > Fread(...,fp);
> >
> > Now there is no segmentation fault, job done.
> 
>      When your smoke alarm jolts you awake in the middle of the
> night, do you fix the problem by stuffing cotton in your ears
> and going back to sleep?
> 
>      When the BRAKE TROUBLE light on your car's dashboard refuses
> to go out, do you put a piece of tape over it?

I actually heard a story a while back about a group of people
doing something very similar.  I'm not remembering details now
(and that bugs me), but possibly it had to do with a red light on
their phones that indicated voice mail and them taping over it.

>      When you're eating the leftovers from last week's sushi and
> find that it smells and tastes rotten, do you pile on extra
> wasabi to stun your taste buds?
> 
>      Do you wear Joo Janta Peril-Sensitive Sunglasses?

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.

[toc] | [prev] | [next] | [standalone]

#8520 — [OT] Re: Fread problem

On 7/19/2011 1:17 PM, blmblm@myrealbox.com wrote:
> In article<ivsttt$u4o$1@dont-email.me>,
> Eric Sosman<esosman@ieee-dot-org.invalid>  wrote:
>> [...]
>>       When the BRAKE TROUBLE light on your car's dashboard refuses
>> to go out, do you put a piece of tape over it?
>
> I actually heard a story a while back about a group of people
> doing something very similar.  I'm not remembering details now
> (and that bugs me), but possibly it had to do with a red light on
> their phones that indicated voice mail and them taping over it.

     Every now and again the "Car Talk" guys Tom and Ray Magliozzi,
better known as "Click and Clack, the Tappet Brothers," recommend
to a caller that he or she cover an annoying dashboard light with
a piece of Official Car Talk Black Tape.  They then usually offer
to sell the said tape for a mere umpteen bucks, plus shipping.

     I've never heard them take this stance with a brake warning light.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#8522 — Re: [OT] Re: Fread problem

On 2011-07-20, Eric Sosman <esosman@ieee-dot-org.invalid> wrote:
>      Every now and again the "Car Talk" guys Tom and Ray Magliozzi,
> better known as "Click and Clack, the Tappet Brothers," recommend
> to a caller that he or she cover an annoying dashboard light with
> a piece of Official Car Talk Black Tape.  They then usually offer
> to sell the said tape for a mere umpteen bucks, plus shipping.

>      I've never heard them take this stance with a brake warning light.

I haven't heard them do it, but!

We have a 1994 Subaru where the "ABS" (Antilock Brake System) light comes
on after about 30 seconds of driving.  Every time.  The brakes work fine.
We have had three sets of mechanics look at that light.  For various reasons,
it is effectively impossible to extract a diagnostic code from the vehicle
(the terminals that are supposed to report it, and the lights, are physically
MISSING on this particular car!), and mostly they spend an hour or three
studying it, checking things out, and so on, and then inform us that:

1.  It may or may not be serious.
2.  Everything appears to be in good working order.
3.  Even if the ABS fails, the regular brakes are fully independent and
should be fine.
4.  You might as well ignore it.

So it DOES happen.

Similarly, while in principle a segmentation fault is a Very Serious Thing,
we have a standard procedure that if a *build* segfaults, and then never
does it again on any machine, we disregard that.  We do enough builds on
enough hardware that we do have a non-zero incidence rate of "apparently a
bit got flipped".

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[toc] | [prev] | [next] | [standalone]

#8365

Jack <spamtrap@trashcan.invalid> writes:

> On Sat, 16 Jul 2011 10:25:41 +0100, Dr Nick wrote:
>
>> Jack <spamtrap@trashcan.invalid> writes:
>> 
>>> On Fri, 15 Jul 2011 21:43:53 +0000, John Gordon wrote:
>>>> In <ivq9i7$841$1@speranza.aioe.org> Jack <spamtrap@trashcan.invalid>
>>>> writes:
>>>> 
>>>>> I got a strange problem with Fread:
>>>> 
>>>>> It crashes my program from time to time, in one of its internal
>>>>> memcpy calls.
>>>> 
>>>> When things like this happen it is nearly always because of a memory
>>>> corruption bug elsewhere in your program, not because of a bug in a
>>>> library function like fread().
>>>> 
>>>> C is, unfortunately, a fragile language.  If you copy more to a buffer
>>>> than it can hold, or call free() on a bad value, or call free() twice
>>>> on the same value, you've just corrupted the memory space of your
>>>> program and anything can happen from that point onward, including
>>>> crashes in library functions such as fread().
>>>> 
>>>> If your program is a simple one, go over it again and try to identify
>>>> any areas where you might have committed the above errors.  If it's a
>>>> complex program, you might use a memory analyzer such as efence or
>>>> valgrind.
>>>
>>> Yes...
>>> Actually, I think it's a memory error somewhere that causes really
>>> indirectly this bug.
>>> But I find it strange that even a memory error makes a fread with
>>> proper parameters ( I do check this ) fail.
>> 
>> Somewhere the library and the operating system have to store things like
>> the details of the underlying file, the position in it etc.  When you
>> trample over memory you can overwrite this.
>> 
>> In particular, many systems get the buffers for the stdio streams from
>> the same memory pool as you get with malloc.  So do something wrong with
>> a block you've got from malloc and you can really mess the streams up.
>> 
>> And vice versa.  I once managed to get malloc to return "null" by
>> previously fclosing the same file pointer twice.
>> 
>>> I've heard somewhere one can play with the file buffer, so I tried it,
>>> and put MY file buffer, with the Setbuff() function. And it didn't
>>> crash anymore, but the read couldn't read all the files. Some bytes in
>>> the middle were missing (I think it is when I resume the reading, after
>>> having processed the first part)...
>> 
>> That's not incompatible with what I wrote above.
>
> Thanks for your help. I think I've now found a solution.
>
> After the file is first Fopen'd, I make a backup of the internal buffers.
> fp=Fopen(...);
> FILE fback;
> memcpy(&fback,fp,sizeof(FILE));
>
> then before the fread I restore this buffer,
> memcpy(fp,&fback,sizeof(FILE));
> Fread(...,fp);
>
> Now there is no segmentation fault, job done.

That's not a fix.  Your underlying bug is still present; your code is
still broken.  Anything from adding a new line of code to a new compiler
version to a new version of libc to slightly different input than what
you've tested on so far could make it manifest again at any time.

[toc] | [prev] | [next] | [standalone]

#8392

On Sat, 16 Jul 2011 14:57:13 -0600, Joe Pfeiffer wrote:

> Jack <spamtrap@trashcan.invalid> writes:
> 
>> On Sat, 16 Jul 2011 10:25:41 +0100, Dr Nick wrote:
>>
>>> Jack <spamtrap@trashcan.invalid> writes:
>>> 
>>>> On Fri, 15 Jul 2011 21:43:53 +0000, John Gordon wrote:
>>>>> In <ivq9i7$841$1@speranza.aioe.org> Jack <spamtrap@trashcan.invalid>
>>>>> writes:
>>>>> 
>>>>>> I got a strange problem with Fread:
>>>>> 
>>>>>> It crashes my program from time to time, in one of its internal
>>>>>> memcpy calls.
>>>>> 
>>>>> When things like this happen it is nearly always because of a memory
>>>>> corruption bug elsewhere in your program, not because of a bug in a
>>>>> library function like fread().
>>>>> 
>>>>> C is, unfortunately, a fragile language.  If you copy more to a
>>>>> buffer than it can hold, or call free() on a bad value, or call
>>>>> free() twice on the same value, you've just corrupted the memory
>>>>> space of your program and anything can happen from that point
>>>>> onward, including crashes in library functions such as fread().
>>>>> 
>>>>> If your program is a simple one, go over it again and try to
>>>>> identify any areas where you might have committed the above errors. 
>>>>> If it's a complex program, you might use a memory analyzer such as
>>>>> efence or valgrind.
>>>>
>>>> Yes...
>>>> Actually, I think it's a memory error somewhere that causes really
>>>> indirectly this bug.
>>>> But I find it strange that even a memory error makes a fread with
>>>> proper parameters ( I do check this ) fail.
>>> 
>>> Somewhere the library and the operating system have to store things
>>> like the details of the underlying file, the position in it etc.  When
>>> you trample over memory you can overwrite this.
>>> 
>>> In particular, many systems get the buffers for the stdio streams from
>>> the same memory pool as you get with malloc.  So do something wrong
>>> with a block you've got from malloc and you can really mess the
>>> streams up.
>>> 
>>> And vice versa.  I once managed to get malloc to return "null" by
>>> previously fclosing the same file pointer twice.
>>> 
>>>> I've heard somewhere one can play with the file buffer, so I tried
>>>> it, and put MY file buffer, with the Setbuff() function. And it
>>>> didn't crash anymore, but the read couldn't read all the files. Some
>>>> bytes in the middle were missing (I think it is when I resume the
>>>> reading, after having processed the first part)...
>>> 
>>> That's not incompatible with what I wrote above.
>>
>> Thanks for your help. I think I've now found a solution.
>>
>> After the file is first Fopen'd, I make a backup of the internal
>> buffers. fp=Fopen(...);
>> FILE fback;
>> memcpy(&fback,fp,sizeof(FILE));
>>
>> then before the fread I restore this buffer,
>> memcpy(fp,&fback,sizeof(FILE));
>> Fread(...,fp);
>>
>> Now there is no segmentation fault, job done.
> 
> That's not a fix.  Your underlying bug is still present; your code is
> still broken.  Anything from adding a new line of code to a new compiler
> version to a new version of libc to slightly different input than what
> you've tested on so far could make it manifest again at any time.

I sure do understand the point everyone's making, and in an ideal world 
I'd get right to the heart of this bug. BUT... the customer pays for 
their support contract annually in advance, any time we have to spend on 
maintenance from that contract is just a cost to our company, so we get 
strong pressure from management to get quick 'n' easy fixes out the door.

Anyways, if the problem reoccurs in future, with any luck it'll end up on 
some other maintenance programmer's books not mine. :)

[toc] | [prev] | [next] | [standalone]

#8393

On 07/18/11 08:45 AM, Jack wrote:
>
> I sure do understand the point everyone's making, and in an ideal world
> I'd get right to the heart of this bug. BUT... the customer pays for
> their support contract annually in advance, any time we have to spend on
> maintenance from that contract is just a cost to our company, so we get
> strong pressure from management to get quick 'n' easy fixes out the door.

Wouldn't the quickest solution have been to use the appropriate tool to 
find the bug?

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#8395

On 07/17/2011 04:45 PM, Jack wrote:
> On Sat, 16 Jul 2011 14:57:13 -0600, Joe Pfeiffer wrote:
...
>> That's not a fix.  Your underlying bug is still present; your code is
>> still broken.  Anything from adding a new line of code to a new compiler
>> version to a new version of libc to slightly different input than what
>> you've tested on so far could make it manifest again at any time.
> 
> I sure do understand the point everyone's making, and in an ideal world 
> I'd get right to the heart of this bug. BUT... the customer pays for 
> their support contract annually in advance, any time we have to spend on 
> maintenance from that contract is just a cost to our company, so we get 
> strong pressure from management to get quick 'n' easy fixes out the door.

You do understand, I hope, that your "quick 'n' easy fix" may have
indeed been quick and easy, but is not a fix? That this customer, or
perhaps other customers, will come back in the future asking for a fix
to the problem that you failed to fix? Sooner or later, unless your
company goes out of business first (poor customer service can do that to
a company), someone will have to actually track down and fix this bug.
Why not do it now?

> Anyways, if the problem reoccurs in future, with any luck it'll end up on 
> some other maintenance programmer's books not mine. :)

Since you didn't actually fix the bug, only plastered over the symptoms,
there's no question that it will come back in the future. If the person
who actually fixes it is sufficiently competent, he'll realize that your
bizarre code was intended to be a completely inadequate fix. If your
company has adequate version control (which is strongly
counter-indicated by the other things you've said), he'll be able to
determine that you perpetrated that nonsense, instead of actually
dealing with the problem, and you'll be held responsible.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#8397

On 07/18/11 09:06 AM, James Kuyper wrote:
> On 07/17/2011 04:45 PM, Jack wrote:
>> On Sat, 16 Jul 2011 14:57:13 -0600, Joe Pfeiffer wrote:
> ....
>>> That's not a fix.  Your underlying bug is still present; your code is
>>> still broken.  Anything from adding a new line of code to a new compiler
>>> version to a new version of libc to slightly different input than what
>>> you've tested on so far could make it manifest again at any time.
>>
>> I sure do understand the point everyone's making, and in an ideal world
>> I'd get right to the heart of this bug. BUT... the customer pays for
>> their support contract annually in advance, any time we have to spend on
>> maintenance from that contract is just a cost to our company, so we get
>> strong pressure from management to get quick 'n' easy fixes out the door.
>
> You do understand, I hope, that your "quick 'n' easy fix" may have
> indeed been quick and easy, but is not a fix? That this customer, or
> perhaps other customers, will come back in the future asking for a fix
> to the problem that you failed to fix?

It's probably worse than that.  The bug still exists, but the symptoms 
will have moved.  So rather than an obvious failure, they'll probably 
end up with either random crashes or silent data corruption.  Nice.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web