Date:	Thu, 14 May 92 17:21:27 -0400
From:	davidf AT lyra DOT cs DOT umbc DOT edu (Mr. David W. Flater)
To:	djgpp AT sun DOT soe DOT clarkson DOT edu
Subject:	Re: HD Errors
Status:	O

bernd AT bwhwob DOT bs DOT open DOT de (Bernd Wiegmann) writes:

>davidf AT lyra DOT cs DOT umbc DOT edu (Mr. David W. Flater) writes:
>
>> So far I know the following about this problem:
>> [..]
>> I would like to know if anyone can refute the new claim, which is:
>> 
>> *  It only happens when you enable optimization with -O.
>> 
>> I was thinking that the problem was with the extender, but if it is related t
>> optimization, then perhaps it is not.
>
>The optimization takes more memory than the normal compilation
>process. So it might be a memory problem. Did you compile C++ or
>C Code ? C++ uses a lot more memory and should cause much more
>memory problems than C.

Memory problems???  Like what?  In hardware you mean?  There are lots of people
having this problem, not just me.

That was an old message you got.  Since I sent that it has started to look as
if the problem is not just with -O, and not necessarily just with djgpp,
although I personally have never had the problem with anything except programs
compiled under djgpp.  Other people have reported having the problem with just
about any software that really works the hard drive.

I am trying to run a -few- big programs with just 2 megs of RAM.  -Most- of my
programs don't need much memory at all and are perfectly happy with Turbo C.  I
was hoping that djgpp could give me a way to run the few remaining programs
that eat memory proportional to n-squared or worse.  Sometimes the compiler
will die with exceptions and segmentation faults, but the main problem is that
the compiled programs die with HD errors after they page for a while.  Upon
rebooting, chkdsk /f has its job cut out; 1.06 leaves even scarier anomalies in
the disk than 1.05 did.

I have been sending all this to the mailing list in hopes that we could
collectively decide exactly what the problem is here, or at least how to work
around it whatever it is.  I originally sent mail to DJ, believing it was a bug
in go32.  It was reassuring to hear that he had had the same problem, and not
so reassuring to hear that his solution was to buy more memory.

People have suggested everything from setting STACKS in CONFIG.SYS to changing
the wait states of the computer.  I took the STACKS advice since it didn't seem
like it could hurt anything even if it did nothing.  I will also try removing
-O or otherwise slowing down the program to not work the HD so hard.  Right now
I can't get immediate feedback for a variety of reasons, not the least of which
is that the compiler crashes a lot.  :-/

-------------------------------------------------------------------------------
Mr. David W. Flater      davidf AT cs DOT umbc DOT edu                 "Nothing works."
Disclaimer:  Nobody ever holds my opinions.               "Nothing EVER works!"
-------------------------------------------------------------------------------

- Raw text -