Path: utzoo!utgpu!attcan!uunet!ubvax!ardent!rap
From: rap@ardent.UUCP (Rob Peck)
Newsgroups: comp.sys.amiga.tech
Subject: Re: divide by 0 problem in "info"?  Also: GOMF
Summary: avoid at least: freeing already free memory
Message-ID: <571@ardent.UUCP>
Date: 1 Sep 88 17:10:12 GMT
References: <1841@kalliope.rice.edu> <2914@hubcap.UUCP>
Organization: Dana Computer, Inc., Sunnyvale, CA
Lines: 42

In article <2914@hubcap.UUCP>, rchampe@hubcap.UUCP (Richard Champeaux) writes:
> 
>     GOMF seems to catch a lot of the system errors, both the "Task Held"
> and the GURU ones.  However, it doesn't tend to catch the ones I got it for,
> the ones that the programs I'm writting create.  To quote the manual:
> 
>           The third is a catastrophic system failure chaaracterized by an
>      instant lockup of the entire system.  Unfortunately, this 'sudden death'
>      is fatal to all programs, including GOMF.  Luckily, programmers so inept

I found that the most common cause of instant lockup (at least when -->I<--
cause it) is asking to free a memory segment that has already been freed.
It seems that once a free memory list has been mangled, Amy does not
quite know what to do --- 

	"Do I have any memory available to put up a dead end requester, 
	 well, maybe I'd stomp on something because this memory list is 
	 so rotz'ed up I don't quite know what to do... aha, I'll just lock
	 up... the programmer (or user) will recognize that I have a problem 
	 and nerve pinch me back to health"

Actually, maybe lets make this an official request for 1.4 -- make it impossible
to lock up the system under at least this particular condition (and any
others for which the reason for the lockup can be determined).  No, I
don't know HOW, but maybe the lockup condition can be reworked to wait
a few seconds (so the user might recognized that it was locked), then
stomp/unstomp something so that a dead end requester can be put up --
like maybe even if the memory list is messed up, make a fast assumption
that there is at least 512k in the machine and reinitialize the memory
and/or screen so that the requester can be put up with the appropriate
message.  The access to data is probably already too bad off and it
might be more desireable to allow the machine to recover on its own.

One thing I had not tried yet, though ... does the system drop into
ROMWack when a lockup happens?  If so, programmers might still benefit,
even during lockup, if an external terminal could do a little bit of
post-mortem analysis.  You'd have to do a bit of printf'ing to the
external terminal before the crash, so you'd know where Amy loaded
and created various structures, but maybe there'd be a way to look
at things if you crash consistently each time you run it.

Rob Peck