Fread problem

[James Kuyper]

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.

 

[Ian Collins]

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.

 

[Joe Pfeiffer]

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.

Who do you work for, if I may ask? I definitely wouldn't want any of my
friends to get support contracts through them...

 

[Geoff]

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.

This is totally irresponsible. I can't believe you get paid for this
kind of workmanship. I can't believe you don't have more pride in your
work. I don't know where you work but declaring this "fixed" in this
manner would get you fired where I work. I hope you change your mind
and track down this error because you would gain valuable insight into
the program and add actual value to the product instead of driving
your support people batty with phantom crashes.

 

[J. J. Farrell]

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.

 

[Seebs]

This is totally irresponsible.

Totally agreed.

I can't believe you get paid for this
kind of workmanship. I can't believe you don't have more pride in your
work.

Clearly, you have not had much experience with the general qualities of the
programming marketplace.

I don't know where you work but declaring this "fixed" in this
manner would get you fired where I work. I hope you change your mind
and track down this error because you would gain valuable insight into
the program and add actual value to the product instead of driving
your support people batty with phantom crashes.

Note the careful lack of personally identifying information. Pretty sure
"Jack" is well aware of how shoddy this is.

-s

 

[Todd Carnes]

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.

I may be wrong, but I'm pretty sure this just cost you any assistance you
might possibly seek from this group in the future.

Todd

 

[Geoff]

Clearly, you have not had much experience with the general qualities of the
programming marketplace.

True. I've been lucky. I've had the pleasure of working with some
very sharp people and very few get-it-out-the-door types.

 

[Nick Keighley]

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

remind me not to do business with your company...

 

[Eric Sosman]

]

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.

So, you accept payment for work that you know to be substandard?
You take a customer's money in exchange for "fixes" that fix nothing?

I wish I knew where you lived, so I could robo-sign foreclosure
papers on your house.

 

[Keith Thompson]

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.

 

[Ben Bacarisse]

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.

 

[Joe Pfeiffer]

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.

 

[Keith Thompson]

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.


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.

 

[Hans Vlems]

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?


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.

You're wasting your breath: the OP is not a programmer at all.
Hans

 

[John Gordon]

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.

 

[Jack]

This is totally irresponsible. I can't believe you get paid for this
kind of workmanship. I can't believe you don't have more pride in your
work. I don't know where you work but declaring this "fixed" in this
manner would get you fired where I work. I hope you change your mind and
track down this error because you would gain valuable insight into the
program and add actual value to the product instead of driving your
support people batty with phantom crashes.

OK, knock it off guys.

Let me tell you how the world works. Five of our team have lost their
jobs in the last 2 years - thanks a lot, Barack Obama -- working for the
elite in Washington and disdaining real America outside the Beltway.

I have a wife and three kids to keep. Real estate prices round here have
collapsed -- gee, thanks again, Barack -- and the house is now worth less
than our mortgage. If I start to default on my mortgage payments, we're
out on the street. Programming jobs don't grow on trees. If I lose my
job, I'll be defaulting on those payments.

When my boss says he wants customer faults patched up as quickly as
possible and damn the long term effects, I'm going to do exactly what he
says and hope to God it's enough to keep me on the books.

All you people going on with your ideal of programming to perfection -
yeah, I agree with that. But it's not possible for me where I am right
now and there's nothing I can do about that.

Anyways, thanks to everyone who's helped with this problem.

 

[Keith Thompson]

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.

 

[Ian Collins]

When my boss says he wants customer faults patched up as quickly as
possible and damn the long term effects, I'm going to do exactly what he
says and hope to God it's enough to keep me on the books.

All you people going on with your ideal of programming to perfection -
yeah, I agree with that. But it's not possible for me where I am right
now and there's nothing I can do about that.

You missed the point - running the code with an access checker to find
the true bug would probably have been *quicker* than kludging a fix.

 

[Anders Wegge Keller]

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.