mit-scheme-devel
[Top][All Lists]
Advanced

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

Re: [MIT-Scheme-devel] Bug: Poor error message; maybe a sign of somethin


From: Taylor R Campbell
Subject: Re: [MIT-Scheme-devel] Bug: Poor error message; maybe a sign of something worse?
Date: Tue, 20 Sep 2011 19:10:19 +0000
User-agent: IMAIL/1.21; Edwin/3.116; MIT-Scheme/9.1

   Date: Mon, 22 Aug 2011 20:31:15 +0000
   From: Taylor R Campbell <address@hidden>

   I'm looking into changing the actual limit, which looks to be a little
   fiddly.  There may also be other limits lurking throughout the code
   that nobody has documented or analyzed, although probably most of them
   are 32-bit limits rather than 16-bit limits like this one.

To recap:  Alexey's symptom is that LIAR chokes when it generates a
straight-line sequence of machine code that exceeds 64 kilobytes.  The
immediate source of the problem is that the format word just before
any straight-line sequence of code saying how far it is from the start
of the previous one is a 16-bit field.

I could `fix' it by taking, say, the maximum value and reinterpreting
it to mean an extra-long 32-bit format word precedes it or something.
However, that doesn't solve the real problem, which is that straight-
line sequences of code are uninterruptible, either by ^G or by a heap
overflow or whatever.

We allow interrupt handlers -- including the heap overflow interrupt
handler which runs the garbage collector[*] -- to run only at safe
points, at the beginning of a straight-line sequence of code, when the
machine is in an easily understandable state: the registers contain
garbage and the stack looks good.

As long as the code polls for interrupts periodically, this is OK.
Currently, `periodically' is at most every 64 kilobytes of machine
instructions, which is reasonable enough, but expanding that to every
four gigabytes of instructions sounds rather sketchy.

Another approach would be to let interrupt handlers run anywhere
they're not blocked, like Unix signal handlers.[**]  However, this is
not feasible to implement now, because it requires interrupt handlers
to be able to handle much hairier machine states, and either parse the
instruction stream or formalize register maps or do other complex
things like that.  That would take substantial re-engineering of large
chunks of the compiler and runtime, which I'm not about to do and I
don't think anyone else is either.

I don't see any nice way to work around or solve this problem, without
just splitting the input to LIAR into separate procedures, which is
what I have advised Alexey to do.

[*] As an aside, I don't think we test for heap overflow reliably: I
suspect the heap can overflow before we poll for interrupts.
Certainly there are no formally engineered limits in place, or
bookkeeping in the code generator, to prevent that from happening.
But that's a separate issue.

[**] Internally on Unix, we use signal handlers, but not to run Scheme
code -- only to set a flag that compiled Scheme code polls at the
start of straight-line sequences of code in order to conditionally
branch to a Scheme interrupt handler.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]