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 3 of 3 — ← Prev page 1 2 [3]

#8510

In article <kqCdnVWLUpLkV7jTnZ2dnUVZ_uCdnZ2d@bestweb.net>,
Kenneth Brody  <kenbrody@spamcop.net> wrote:
> On 7/19/2011 1:19 PM, blmblm@myrealbox.com wrote:
> > In article<ivvhlc$148$1@speranza.aioe.org>,
> > Jack<spamtrap@trashcan.invalid>  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.
> >>
> >> Anyways, if the problem reoccurs in future, with any luck it'll end up on
> >> some other maintenance programmer's books not mine. :)
> >
> > One wonders how/whether your "fix" will complicate the job of that
> > other maintenance programmer.  At least you put in a comment, right?
> > though really, it might be tricky to word a comment in a way that
> > would be helpful to other programmers without being something you
> > would not want repeated to your boss.
> 
> /*
>   * The following line was added to hide a memory corruption bug.
>   * The boss says "do something ASAP to make the customer think that
>   * it's fixed, even if it really makes things worse".  I know that
>   * this isn't a fix, in any sense of the word, but this is the only
>   * thing I can come up with that will let me keep my job.  (At least
>   * for now.)
>   *
>   * P.S.  Good thing we don't use any version control software, so I
>   * don't have to check in this comment under my name.
>   */

:-)?  But not really, maybe.

> > I've been a maintenance programmer, and it's likely that in that
> > capacity I came up with my share of ugly hacks (hard to remember
> > given that it was many years ago), but this one is -- memorable.
> 
> But, would you remember _why_ you did it?

Probably not unless I recorded the "why" somewhere.  Which, at
that long-ago job, I probably would have done, because my immediate
supervisor was a reasonable and technically competent person.  If
that hadn't been the case -- I don't know.  

(For what it's worth, the only ugly-hack fix I remember from that
job was not mine, but a colleague's, and while I can remember more
or less *what* he did, my recollection of the *why* is dimmer.
We're drifting further and further OT here so maybe I should leave
it at that.)

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

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

#8367

On Sat, 16 Jul 2011 20:23:54 +0000 (UTC), Jack
<spamtrap@trashcan.invalid> wrote:

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

This is not a correct solution. This is a kludge. Your code is still
bugged and it WILL fail again.

Why do you keep capitalizing Fopen and Fread? The standard library
calls are fopen and fread. Are you using someone else's wrapper or
libraries?

You have been advised to use valgrind to find your bug. It appears you
haven't followed that advice and you still have no clue why your code
is failing. Learn to use the toolset. At a minimum you should have
been able to trace back your call stack and find the error in a
debugger.

Post code, your methods are suspect.

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

#8368

In <s504275sfp83vg2bmjacq9khbjke2qsih6@4ax.com> Geoff <geoff@invalid.invalid> writes:

> At a minimum you should have been able to trace back your call stack
> and find the error in a debugger.

A call trace won't really help, will it?  The memory corruption likely
happened in some previous call and isn't on the stack anymore, which is
exactly why errors like this are hard to find.

> Post code, your methods are suspect.

He said it's a large program, so posting it may be problematic.

-- 
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]

#8376

On Jul 16, 10:23 pm, Jack <spamt...@trashcan.invalid> wrote:
> On Sat, 16 Jul 2011 10:25:41 +0100, Dr Nick wrote:
> > Jack <spamt...@trashcan.invalid> writes:
>
> >> On Fri, 15 Jul 2011 21:43:53 +0000, John Gordon wrote:
> >>> In <ivq9i7$84...@speranza.aioe.org> Jack <spamt...@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.

In addition to what everyone else has told you, here's a few rules of
thumb:

* A bug is more likely to reside in the code most recently written
instead of a widely used library.
* A bug isn't solved until you know what you did wrong.
* It's always your fault and the mistake you made is most likely very
silly, once you spot it.

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

#8405

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.

I thought that was pretty funny until I realised you were serious.

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

#8434

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.

That's actually a reasonable first step in tracking down the real
problem.

If I were working on this, I might do the following.

First, change Fopen and Fread to fopen and fread, respectively.

Then, rather than copying the saved contents of fback back into
*fp, I'd compare them.  If you haven't called any stdio functions
between the two memcpy() calls, then the contents of *fp shouldn't
have changed.  If they have, then something is stepping on memory
it doesn't own, and you can start narrowing down where it happened.
For example, you might sprinkle some assert() statements through
the intervening code:

    assert(fback == *fp);

(this assumes FILE is a struct type, which it probably is).

With just a little work, you should be able to determine exactly
where the real problem is.

Of course, just papering over the problem by copying the contents
of fback back into *fp is not a "solution", it's malpractice.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#8437

Keith Thompson <kst-u@mib.org> writes:

> 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.
>
> That's actually a reasonable first step in tracking down the real
> problem.
>
> If I were working on this, I might do the following.
>
> First, change Fopen and Fread to fopen and fread, respectively.
>
> Then, rather than copying the saved contents of fback back into
> *fp, I'd compare them.  If you haven't called any stdio functions
> between the two memcpy() calls, then the contents of *fp shouldn't
> have changed.  If they have, then something is stepping on memory
> it doesn't own, and you can start narrowing down where it happened.
> For example, you might sprinkle some assert() statements through
> the intervening code:
>
>     assert(fback == *fp);
>
> (this assumes FILE is a struct type, which it probably is).

structs can't be compared with == (as I am sure you know).

  assert(memcmp(&fback, fp, sizeof *fp) == 0);

is probably what want.

> With just a little work, you should be able to determine exactly
> where the real problem is.

I still think that memory tool like valgrind or mudflap (if available)
might get there faster.  The "with just a little work" is often
something of an understatement in my experience.

> Of course, just papering over the problem by copying the contents
> of fback back into *fp is not a "solution", it's malpractice.

-- 
Ben.

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

#8448

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Keith Thompson <kst-u@mib.org> writes:
[...]
>>     assert(fback == *fp);
>>
>> (this assumes FILE is a struct type, which it probably is).
>
> structs can't be compared with == (as I am sure you know).

D'oh!  Yes, I know, I just momentarily forgot, blinded by the fact that
structs can be assigned with "=".

>   assert(memcmp(&fback, fp, sizeof *fp) == 0);
>
> is probably what want.

Yes.

>> With just a little work, you should be able to determine exactly
>> where the real problem is.
>
> I still think that memory tool like valgrind or mudflap (if available)
> might get there faster.  The "with just a little work" is often
> something of an understatement in my experience.

A good debugger might also be useful here.

>> Of course, just papering over the problem by copying the contents
>> of fback back into *fp is not a "solution", it's malpractice.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#8445

Keith Thompson <kst-u@mib.org> writes:

> 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.
>
> That's actually a reasonable first step in tracking down the real
> problem.
>
> If I were working on this, I might do the following.
>
> First, change Fopen and Fread to fopen and fread, respectively.
>
> Then, rather than copying the saved contents of fback back into
> *fp, I'd compare them.  If you haven't called any stdio functions
> between the two memcpy() calls, then the contents of *fp shouldn't
> have changed.  If they have, then something is stepping on memory
> it doesn't own, and you can start narrowing down where it happened.
> For example, you might sprinkle some assert() statements through
> the intervening code:
>
>     assert(fback == *fp);
>
> (this assumes FILE is a struct type, which it probably is).
>
> With just a little work, you should be able to determine exactly
> where the real problem is.

Nice!  That's not an approach to tracking down memory corruption I'd
thought of before.

> Of course, just papering over the problem by copying the contents
> of fback back into *fp is not a "solution", it's malpractice.

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

#8450

In <ln7h7foaac.fsf@nuthaus.mib.org> Keith Thompson <kst-u@mib.org> writes:

> Then, rather than copying the saved contents of fback back into
> *fp, I'd compare them.

> With just a little work, you should be able to determine exactly
> where the real problem is.

Is this really true?  I thought memory corruption errors were quite
difficult to track down precisely because the true error can be far
upstream from the code which finally exhibits the broken behavior.

-- 
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]

#8452

John Gordon <gordon@panix.com> writes:
> In <ln7h7foaac.fsf@nuthaus.mib.org> Keith Thompson <kst-u@mib.org> writes:
>> Then, rather than copying the saved contents of fback back into
>> *fp, I'd compare them.
>
>> With just a little work, you should be able to determine exactly
>> where the real problem is.
>
> Is this really true?  I thought memory corruption errors were quite
> difficult to track down precisely because the true error can be far
> upstream from the code which finally exhibits the broken behavior.

Maybe.  It should at least provide *some* useful information.

We know that the ugly hack of saving and restoring the contents
of the FILE object avoided the crash.  Assuming that the contents
of the FILE object are valid at point A (when they're saved),
and invalid at point B (when they're restored), and that nothing
between points A and B *should* be modifying it, then determining
the earliest point between A and B where the FILE object is actually
modified is likely to tell us something useful.

Of course it's also possible that the code that corrupts the FILE
object does so because something else was corrupted earlier, and
that could be much more difficult to track down.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#8456

On July 18, 2011 16:28, in comp.lang.c, kst-u@mib.org wrote:

> John Gordon <gordon@panix.com> writes:
>> In <ln7h7foaac.fsf@nuthaus.mib.org> Keith Thompson <kst-u@mib.org>
>> writes:
>>> Then, rather than copying the saved contents of fback back into
>>> *fp, I'd compare them.
>>
>>> With just a little work, you should be able to determine exactly
>>> where the real problem is.
>>
>> Is this really true?  I thought memory corruption errors were quite
>> difficult to track down precisely because the true error can be far
>> upstream from the code which finally exhibits the broken behavior.
> 
> Maybe.  It should at least provide *some* useful information.
> 
> We know that the ugly hack of saving and restoring the contents
> of the FILE object avoided the crash.  Assuming that the contents
> of the FILE object are valid at point A (when they're saved),
> and invalid at point B (when they're restored), and that nothing
> between points A and B *should* be modifying it, then determining
> the earliest point between A and B where the FILE object is actually
> modified is likely to tell us something useful.
> 
> Of course it's also possible that the code that corrupts the FILE
> object does so because something else was corrupted earlier, and
> that could be much more difficult to track down.

This is where the difference between a "coder" and a "programmer" becomes
evident.

In my professional life, I've had problems like this one, and a darn sight
less time to solve them than has been experienced here. A good abend dump
(such as a Unix core dump or MVS abend dump), some knowledge of the data
being processed, and the original source code are often the only
information a /programmer/ has to go on. (A /coder/ will, at best, just
code around the problem, and leave the cause of the problem to someone else
to figure out.)

Code analysis tools (such as Valgrind) and code/dump debugging tools (such
as gdb) can give a programmer insight into the root cause of this sort of
error. But, it all comes down to effort; those who won't put the effort
into determining the cause of a problem also won't put much effort into
fixing the problem.

-- 
Lew Pitcher
Master Codewright & JOAT-in-training   | Registered Linux User #112576
Me: http://pitcher.digitalfreehold.ca/ | Just Linux: http://justlinux.ca/
----------      Slackware - Because I know what I'm doing.         ------

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

#8454

John Gordon <gordon@panix.com> writes:

> In <ln7h7foaac.fsf@nuthaus.mib.org> Keith Thompson <kst-u@mib.org> writes:
> 
> > Then, rather than copying the saved contents of fback back into
> > *fp, I'd compare them.
> 
> > With just a little work, you should be able to determine exactly
> > where the real problem is.
> 
> Is this really true?  I thought memory corruption errors were quite
> difficult to track down precisely because the true error can be far
> upstream from the code which finally exhibits the broken behavior.

 That depends on the storage class of the corrupted object. Auto
objects are, at least in my experience, in most cases corrupted by the
same function they are declared in.

 Objects with global scope will be a lot harder to track down, but
looking at a memory map can often give an indication. In my
experience, corruption in those cases are mostly caused by overrunning
a buffer that's placed before the corrupted object.

-- 
/Wegge

Leder efter redundant peering af dk.*,linux.debian.*

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

#8492

In article <ln7h7foaac.fsf@nuthaus.mib.org>,
Keith Thompson  <kst-u@mib.org> wrote:
> 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.
> 
> That's actually a reasonable first step in tracking down the real
> problem.
> 
> If I were working on this, I might do the following.
> 
> First, change Fopen and Fread to fopen and fread, respectively.

I'm mildly curious about that (why the capital letters) myself.

I'm speculating that perhaps the original code used fopen and fread,
but somehow between there and the newsgroup post some tool that
"helps" by capitalizing letters was involved.  I'm reminded of
the occasion, some years ago, when I received code from a student
in the form of a Word document (which apparently had been created
with all Word's default auto-correct stuff turned on).  You can
all probably imagine ....

Maybe the OP will explain.  Or not, given the direction of subsequent
discussion.

[ snip ]

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

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

#8438

On 7/16/2011 4:23 PM, Jack wrote:
[...]
> Thanks for your help. I think I've now found a solution.

No, you've just masked the symptoms.

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

Not unless your job was to find a way to stop this particular instance of 
this particular program from crashing at this particular line of code using 
this particular set of input.  If your job was to find and fix the bug that 
caused the crash in the first place, you haven't done it.

Perhaps what you should do instead is, in a debugger, check the contents of 
fp (not the pointer, but the FILE struct that it points to) and compare them 
to fback.  Yes, some things are expected to change.  Others should not. 
However, you might find out what's corrupted, and lead you to the cause.

-- 
Kenneth Brody

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

#8353

On 07/16/11 09:22 PM, Jack wrote:
> 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.

So try valgrind...

> But I find it strange that even a memory error makes a fread with proper
> parameters ( I do check this ) fail.

Why strange?  All the memory is in one address space, so any part of the 
program can mess with the buffers being used by stdio.

-- 
Ian Collins

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

#8358

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.

Why should this be any surprise at all?  It looks like you're corrupting
memory, so the buffers fread() depends on are failing.

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

Sounds more and more like a wild pointer someplace.

> 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
> : ( 

Start by assuming yacc and lex are working correctly, do your debugging
on the yacc and lex source files, and on whatever utility C functions
you've defined.  lex and yacc output isn't meant to be human readable;
trying to understand what they're putting out is really useless for
debugging purposes.

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

#8359

In <ivrl7v$3gb$1@speranza.aioe.org> Jack <spamtrap@trashcan.invalid> writes:

> But I find it strange that even a memory error makes a fread with proper
> parameters ( I do check this ) fail.

Unfortunately, it has nothing to do with the parameters to fread() being
right or wrong.  Once you corrupt the underlying memory, any function can
go wrong.

Here's an analogy:

Imagine you're a cook at a restaurant.  The restaurant has lots of recipes
that have been tested and you know they work.

One day, a customer orders pancakes.  You cook them up and serve them.
However, the cook on the previous shift didn't seal the flour container
properly, so the flour had weevils in it.  The pancakes are rotten and
the customer gets sick.

Nothing was wrong with the recipe (the function arguments); you did
everything right.  But an ingredient (memory) was corrupted and so the
function crashes (pancakes are rotten).

-- 
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] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

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

csiph-web