Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!pollux.usc.edu!papa
From: papa@pollux.usc.edu (Marco Papa)
Newsgroups: comp.sys.amiga
Subject: Re: 2091 address zero problems
Keywords: Nope nada zip zilch
Message-ID: <26032@usc.edu>
Date: 19 Jul 90 18:06:15 GMT
References: <38936@sequent.UUCP> <3343@usceast.UUCP>
Sender: news@usc.edu
Organization: Felsina Software, Los Angeles, CA
Lines: 43

In article <3343@usceast.UUCP> yarnall@usceast.UUCP (Ken Yarnall) writes:
>I got my ProWrite 3.0 upgrade *after* I had updated the filesystem on my 2091
>(in my 2500/30), which a thread in c.s.a.tech awhile back had indicated would
>clear up the `garbage-at-location-zero' problem.  When I tried to start
>ProWrite op, it promptly crashed.  I called New Horizons, told the tech. rep.
>what had happened, and he said "I bet you have a 2091."
>
>What he said is that the roms on the 2091 have some inadvertently released
>debugging software, that sets location zero to a non-NULL value.  He didn't
>explain to me why his program crashed because of this (which it should not
>have, IMHO), but he did say that his information came from Commodore.  He was
>clear in that the problem was in the rom, and not in the filesystem.
>
>New Horizons sent me ProWrite 3.0.1 in a matter of days.  Since, I have
>gotten by on a little program that clears the zero spot, that I run from my
>startup-sequence.  It allows JR-Comm 1.0 to run, for instance.

Let me put it this way. It is true that the drivers for the A2091 and A590
do put some debugging stuff (non-zero) at location zero, BUT it is also
true that the programs that bomb in this situation ARE the culprits. What
these program do is the following: they use pointers statically un-initialized
(therefore zero) and READ the value pointed by them, BEFORE initializing
them.  So they read location zero.  Of course what they do is "random", but
if they read the data and use it as pointer they'll point back to zero
and the dereference will get zero again.  Problem is, if location zero is NOT
zero (like on the A2091) they'll reference some random location in memory
and start using the data at that location. That's why some of these programs
will work fine (they don't crash, just by chance) in one case, and they
GURU in the other one.

Of course this bug is NOT very easy to find since it can't be found on a
68000.  I.e. sdb  or cpr (the debuggers) can't be used to check for a "read"
access in low memeory. They can only be used to monitor write access. This
is also the reason why all those other tools like memwatch are useless, since 
they also can only check for write access, not read.  The only useful tool is 
Bryce's Enforcer (on the DevCon '90 disk) that can be used on any system 
with an MMU and that can check for incorrect read access on low memeory.

-- Marco

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"Xerox sues somebody for copying?" -- David Letterman
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=