[Prev][Next][Index][Thread]

bug found in kernel mods



Dear Folks,

	One of the modifications that we're working on is the ability  
to use Macintosh formatted floppies directly from Executor (rather  
than having to go though HFS_XFer).  However, we ran into problems  
when we began running programs directly off of floppies.  A close  
inspection showed that the fast a-line dispatching kernel mods were  
corrupting the user stack pointer.

	We now have a new version of "ardimods.s", which appears to  
fix the bug.  This bug appears to have the side effect of sometimes  
crashing Executor when Executor first starts up and when Executor has  
just printed something. I have placed a copy of our new "ardimods.s"  
in:

unmvax.cs.unm.edu:/usr/spool/ftp/pub/ardi/Source/ardimods.s

	I will be happy to mail it to anyone who doesn't have access  
to ftp (it's only 126 lines long).  The new mods will automatically  
be part of Exector-MSW V1.2 which has been delayed a bit by this bug  
and some display postscript bugs we've bumped into.

TECHNICAL DESCRIPTION THAT YOU DON'T NEED TO READ FOLLOWS:

	I suspect what was happening is that either the copyin or the  
copyout was causing a page-fault and the page-fault handling code  
expected us to have saved more state than we did; because the problem  
appears to be limited to unexpected crashes of Executor (most likely  
when Executor is just starting, or just after you've printed a  
document), it may be as simple as the page-fault handling code  
assuming that it can manipulate the user stack pointer with impunity,  
since it is saved at the beginning of normal traps and restored at  
the end of normal traps (our a-line dispatching code deliberately  
tries to save as little state as possible, to keep a-line traps  
dispatching as quickly as possible; the problem is that since we  
don't have the source to mach, it's hard to tell what the minimum  
amount of state to store is).

	--Cliff