[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