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

#8449

On Jul 17, 11:06 pm, James Kuyper <jameskuy...@verizon.net> 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? 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

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

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

#8400

Jack <spamtrap@trashcan.invalid> writes:

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

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

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

#8401

On Sun, 17 Jul 2011 20:45:32 +0000 (UTC), 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. :)

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.

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

#8406

On 2011-07-18, Geoff <geoff@invalid.invalid> wrote:
> On Sun, 17 Jul 2011 20:45:32 +0000 (UTC), Jack
><spamtrap@trashcan.invalid> wrote:
>>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.

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

#8408

On 18 Jul 2011 04:08:33 GMT, Seebs <usenet-nospam@seebs.net> wrote:

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

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

#8451

On Sun, 17 Jul 2011 17:56:07 -0700, Geoff wrote:
> On Sun, 17 Jul 2011 20:45:32 +0000 (UTC), 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. :)
> 
> 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.

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

#8455

On 07/19/11 08:20 AM, Jack wrote:
>
> 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.

-- 
Ian Collins

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

#8469

Jack wrote:

> On Sun, 17 Jul 2011 17:56:07 -0700, Geoff wrote:
>> On Sun, 17 Jul 2011 20:45:32 +0000 (UTC), 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. :)
>> 
>> 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.
Hmm, moral relativism rears its ugly head, "its not whats right but 
whats right for me"
Man! I sure hope you arent working on some kind of life/safety 
software! e.g aircraft flight control sw.
Hopefully your just screwing people buying a notepad like editor.
Cat22

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

#8477

On 07/18/2011 04:20 PM, Jack wrote:
...
> OK, knock it off guys.

The key thing that I don't think you fully comprehend is just how
short-sighted your non-fix was. It's not going to wait until next year
to come back and bite you - it's the kind of thing that is likely to
come back next week, or next month at the latest. Is your boss really so
short-sighted that he doesn't even care about next month?

The fact that your fix "worked", even in the very limited short-sighted
sense that you're using, implies that something that shouldn't be, is
writing to memory inside of *fp. That's why, by restoring that memory to
its original form, you got fread() to work correctly. However, computer
programs seldom write to memory unless they intend to read from it at
some later time. When the other parts of your program try to read the
values that were written in the wrong location, there's two main
possibilities:

1. They will read it from the correct location.
2. They will read it from the same wrong location that the data was
originally written to, which means that they will read the replacement
data you overwrote it with.

Either way, they will NOT be reading the values that were originally
written to the wrong location. Few programs are likely to work correctly
when the value read from a non-volatile memory location differs from
what was supposed to be written there.

If you were running into this problem during an fclose() call that
happened to be the very last thing your program does, then those issues
wouldn't matter very much. However, a call to fread() is almost always
followed, sooner or later, by more data processing, and something you
haven't even noticed yet is probably already going wrong.

[Political ranting and raving snipped].
> 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.

Your boss is, ultimately, responsible for such decisions. However, be
very careful how far you go in using that as an excuse for sloppy job
performance. I learned the hard way that just because your boss says
"it's more important to get this out by the deadline, than to get it
correct", doesn't mean that you won't be in trouble if it behaves
incorrectly. I was lucky - my boss at least eventually admitted,
publicly, that he might have forgotten that he gave me such
instructions, and afterwards he was much more cautious about giving me
similar instructions. I don't think you can count on your boss being so
honest about it.

At the very least, get such instructions in writing from your boss. If
he won't commit them to writing, write down what he's said yourself and
send it to him, asking for confirmation in writing. If he refuses, you
can reasonably assume that what he's afraid to leave documentary
evidence that he gave you such orders, which is generally a very bad
sign. He'll almost certainly blame the resulting problems on you when it
comes time to pay the piper. That means that you'll be the first out the
door when the next round of layoffs come.

Even if you get it in writing, that might not be enough to save your
job. Every time you take such a short-cut to save time now, someone will
pay for it in the future, even if your boss wants to deny the existence
of that future, and that someone might be you.

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

The idea that there's nothing you can do about this is a self-fulfilling
prophecy.  I'd recommend that you start preparing immediately to search
for a new job. Even if you don't get blamed for the problems caused by
obeying your boss's instructions, if his attitudes are typical of the
management of your company, then it's likely to go out of business soon.
Since you'll need to start your job search soon, anyway, why not search
for a company with a better attitude towards product quality?
-- 
James Kuyper

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

#8485

On 18-Jul-11 15:20, Jack wrote:
> Let me tell you how the world works. Five of our team have lost their 
> jobs in the last 2 years ...
> 
> 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.

Have you not considered that such a short-sighted outlook and resulting
poor customer service is likely _why_ your company is laying off
employees?  My employer has been on a hiring spree for the last several
years, and we're raking in record profits.  How do we do that in a bad
economy?  By making products that are /higher quality/ than our
competitors and offering great customer service.  We don't kludge around
problems; we /fix/ them.

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

With that attitude, no, there's probably not; I sure as heck wouldn't
want to hire you.

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

The best thanks would be to not ignoring their advice.

> ... thanks a lot, Barack Obama -- working for the elite in Washington
> and disdaining real America outside the Beltway. ...

If you want to post political diatribes, there are plenty of newsgroups
for that.  It's off-topic here, though.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

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

#8407

On Sun, 17 Jul 2011 20:45:32 +0000, 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.
> 
> 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

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

#8413

On Jul 17, 9:45 pm, Jack <spamt...@trashcan.invalid> wrote:
> On Sat, 16 Jul 2011 14:57:13 -0600, Joe Pfeiffer wrote:
> > Jack <spamt...@trashcan.invalid> writes:
>
> >> 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.
>
> > 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. :)-

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

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

#8420

On 7/17/2011 4: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.

     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.

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

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

#8440

On 7/18/2011 7:22 AM, Eric Sosman wrote:
> On 7/17/2011 4: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.
>
> 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.

"We had some problem with the payment records, so we just restored last 
year's data.  It's not our fault the computer said the last payment you made 
was over a year ago."

-- 
Kenneth Brody

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

#8439

On 7/17/2011 4:45 PM, 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.
>
> Anyways, if the problem reoccurs in future, with any luck it'll end up on
> some other maintenance programmer's books not mine. :)

You'll make a fine CEO or politician some day.

"I came up with the quickest, cheapest method I could think of to mask the 
symptoms.  The problem is still there, but I'll be long gone before anyone 
notices, and the next guy will be blamed for it."

A good programmer, however, you are not.

-- 
Kenneth Brody

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

#8467

On 7/18/2011 1:49 PM, Kenneth Brody wrote:
> On 7/17/2011 4:45 PM, 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.
>>
>> Anyways, if the problem reoccurs in future, with any luck it'll end up on
>> some other maintenance programmer's books not mine. :)
>
> You'll make a fine CEO or politician some day.
>
> "I came up with the quickest, cheapest method I could think of to mask
> the symptoms. The problem is still there, but I'll be long gone before
> anyone notices, and the next guy will be blamed for it."
>
> A good programmer, however, you are not.

     s/good//

     Elsethread, this loser complains that "programming jobs don't
grow on trees."  Even if they did it's not clear how he'd find them,
situated as he is in the muck at the bottom of a stagnant sewer.

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

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

#8471

On Jul 18, 5:31 pm, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
> On 7/18/2011 1:49 PM, Kenneth Brody wrote:
>
>
>
>
>
> > On 7/17/2011 4:45 PM, 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.
>
> >> Anyways, if the problem reoccurs in future, with any luck it'll end up on
> >> some other maintenance programmer's books not mine. :)
>
> > You'll make a fine CEO or politician some day.
>
> > "I came up with the quickest, cheapest method I could think of to mask
> > the symptoms. The problem is still there, but I'll be long gone before
> > anyone notices, and the next guy will be blamed for it."
>
> > A good programmer, however, you are not.
>
>      s/good//
>
>      Elsethread, this loser complains that "programming jobs don't
> grow on trees."  Even if they did it's not clear how he'd find them,
> situated as he is in the muck at the bottom of a stagnant sewer.

Well said.

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

#8491

In article <ivvhlc$148$1@speranza.aioe.org>,
Jack  <spamtrap@trashcan.invalid> wrote:
> 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:

[ snip ]

> >>>> Actually, I think it's a memory error somewhere that causes really
> >>>> indirectly this bug.

[ snip ]

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

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.

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.

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

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

#8499

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

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

-- 
Kenneth Brody

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

#8504

Kenneth Brody wrote:
 
> /*
>   * 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.
>   */

Here's one possible way that things might end up:

Eventually, the bug really gets fixed.

After the code is thoroughly tested to make sure,
there's no need to go back and rewrite the code again, is there?

And so, the comment remains.

-- 
pete

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

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

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

csiph-web