NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/sys/mac/system/10241

Text File | 1992-07-21 | 7.6 KB | 144 lines

Newsgroups: comp.sys.mac.system
Path: sparky!uunet!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!The-Star.honeywell.com!umn.edu!noc.msc.net!news.stolaf.edu!lars.acc.stolaf.edu!smithc
From: [e-mail] (Christopher A. Smith)
Subject: Re: Bad F-line instruction?
Message-ID: <[e-mail]>
Sender: [e-mail]
Organization: St. Olaf College, Northfield (aka Cow Country), MN   USA
References: <[e-mail]> <[e-mail]> <[e-mail]>
Distribution: na
Date: Wed, 22 Jul 1992 03:49:51 GMT
Lines: 131

In article <[e-mail]> [e-mail] (Tony Wingo) writes:
>In article <[e-mail]>, Devan F. Dewey
><[e-mail]> wrote:
>>
>>
>>
>> >and then I got this "Bad F-line instruction" error from the Finder.  I
>>
>> Is anyone from Apple listening?? I get this message a lot, too. It would
>> be nice to know what it really means.
>
>It means that the CPU fetched and attempted to execute an op-code whose
>high order 4 bits were all 1's.  Such opcodes are known in the Motorola
>documentation as F-Line Exceptions, and are meant primarily to interface
>with co-processors.  When the processor attempts to execute an F-Line that
>doesn't correspond to an installed co-processor, it throws up it's hands
>and traps into the OS, saying in effect "Here, you deal with it".
>
>The OS, knowing that no legitimate piece of code should have undefined
>F-Lines in it, assumes that said code is horribly corrupted, and presents
>the fatal error alert.
>
>OK, so Bad F-Line instruction means that some code is corrupted. (Actually,
>almost all of those cryptic fatal errors boil down to some code being
>corrupted).  This in turn means that either:
>
>1.  The copy on the disk got corrupted somehow, so that when you execute
>that application (or int this case the Finder) you are executing bum code.
>The only thing to do in this case is to re-install the effected software.
>(NOTE, if you decide that your system is corrupted, drag the system file
>and the finder into the trash before running the installer, to guarantee
>that the installer actually replaces the whole thing).
>
>2.  Some other application or INIT in your system is stepping on the
>failing application in memory.  Try running with no INITS.  If this solves
>the problem, start adding INITS one by one until the problem recurs.  Then
>trash that last INIT.  If it is not an INIT problem, then one of your
>applications is stepping on something it shouldn't (such as the Finder).
>Experiment around until you figure out which one it is, then trash it.
>
>-tony
>
>>>usual disclaimer<<


Tony, let me tell you about my experiences with this Bad F-Line
instruction, just in case my previous posting from about a month ago
has scrolled off...

I've been getting the bad F-LIne errors for a couple of months now.
I've tried narrowing it down to a specific INIT or application, but in
every instance the results have been different; all of my software is
either System 7 compatible or collecting dust on a separate hard
drive.  I've spent more than a week trying to find the culprit, but it
is never conclusive.  Never...  I've replaced the Finder and then had
to rebuild the desktop, but that doesn't always fix the problem.  If
it doesn't, then I either have to replace the Finder again or
replace the System 7 tuneup (1.1.1).  If *that* doesn't work, then the
entire system ahs to be reinstalled.  And in the few instances that
that doesn't fix it, even with no INITs loaded, I have to reinstall
the *entire* hard drive.  Now, if the software is supposedly System 7
compatible and the errors never occur in the same spot, then, to me,
that sounds like something in the System software isn't stable enough.
Possibly.  I'm not a hot shot technician; I'm just saying what seems
somewhat obvious.  If a computer crashes with a bad F-line instruction
with *no* INITs loaded, with no applications in the background, and
while the computer is idle in the Finder, then that suggests to me
that the system software is suspect.  And that's exactly what's
happened to me -- the computer crashing wiht a Bad F-Line error with
nothing in memory save the basic System 7.0.1 software and the Finder.

A co-consultant of mine and I worked one day to find the culprit INIT
or application.  After 10 hours of constant badgering, we found
nothing conclusive.  The error couldn't be duplicated; we couldn't
force it to happen.  Once it did happen, we couldn't gbet around it
but to reinstall the Finder at least.  We ran every application on my
hard drive and ran it extensively.  We ran with virtual memory, with
file Sharing, and all INITs.  We worked it to death, and it ran fine.
But when the Bad F-line instructions started popping up, it was
because we chose a menu in the Finder, or scrolled in an application
that was system 7 compatible -- the most rudimentary things in System
7 compatible applications.  We were both bffled beyond belief and gave
up...  Now I'm just bearing with it and trying not to deep-six my Mac
IIci in the Potomac river here in Washington, D.C. (where I'm actually
at -- gotta love the Internet).

I saved a copy once of the supposedly corrupted Finder and ran it
through ResEdit to see if there were any detectable errors.  None...
The Bad F-Line errors pop up in different places in every instance, in
different applications, under different circumstances.  It perfectly
describes the term "intermittent."  It cannot be duplicated on my
machine, but I do know how to fix it.  But it is very time consuming,
and since I'm a consulnt who charges by the hour, I've lost many hours
to these errors, having to reinstall my system or entire hard drive.
I've run every diagnostic possible on this thing with Mac EKG, with
Snooper, with virus programs, disk checkers, etc, etc, etc, and they
all pronounce the computer to be healthy.  So it must be software.
But sinc emy software is up to date and current, and since the rrors
never occur under the same circumstances, I'm rather inclined to
wonder if something in the Finder or the System software is bad.
Perhaps the lack of solid memory protection or file protection...

How can a program become corrupted, especially more than once a day,
under different circumstances (different or no INITs or applications)?
Maybe I'm not a hot-shot programmer, but that to me sounds like
something wasn't designed too well, with a program being vulnerable to
frequent corruption.  I haven't seen that on any other machine; I
mean, I haven't seen it happen so often.  Even on IBMs under MS
Windows 3.0 with the most flaky versions of Stacker (the PC version of
Autodoubler).

Sorry if I sound frustrated, but I've lost a lot of valuable time at
work having to deal with these Bad F-line errors that can't be
prevented or that take sometimes at least an hour to begin to fix.  If
I tallied up the number of lost hours, we could possibly be talking a
4-digit figure here by the end of next month, seeing how things have
been going lately.  Sometimes I've been tempted to moth-ball my mac
and boost up my PC because it's so much more stable and reliable....

Y'all at Apple, please try to figure out what's going on here.  It's
getting ridiculous for me to constantly have to reinstall the Finder
at least.  That's ridiculous.  That's not a stable system.  Please
either get some good memory protection into the System or find the
culprit by doing some intensive software testing...

Just my $0.03 worth...

  ==================================================================
             Christopher A. Smith
       German & Mathematics -- St. Olaf College, Northfield, MN
             Internet:  [e-mail]