Stacksize runtime bugs.....

Stephen Weeks MLton@research.nj.nec.com
Thu, 17 Feb 2000 15:19:01 -0800 (PST)


> Hmmm... I'm not so sure exactly what the problem is anymore but here's a
> program that typechecks and segfaults. It's completely different from the
> one that caused me problems originally.
> 
> It's a modified "life" benchmark with the polymoprhic equality removed, by
> hand. It was closure coverted into my IL then translated back into CPS. I
> didn't do anything to the code when it passed through my code, and it
> typechecks all the way through.... I've significantly trimmed the basis,
> I've removed all exceptions from the code too.
> 
> It seems to segfault pretty reliably at the same place....
> 
>  http://www.cs.princeton.edu/~danwang/stuff/life.c

I found the problem.  It's not a runtime bug.  What's happening is
that there is a Raise happening but there is no handler in place to
handle it.  I figured this out by instrumenting the Raise macro in
include/machine.h.  There is only one raise in the execution of
life.c, and a handler is never installed.  As far as I know, array
bounds cheecking and unhandled raise is the other way in which a type
correct Cps program can cause a seg fault.  Unhandled raises never
happen in code compiled by MLton because the pass
xml/implement-exceptions always installs a toplevel handler that
prints "toplevel handler not installed" and exits.  This message
should never be seen, unless there are bugs in the basis library,
since the basis library installs a more sensible toplevel handler
which is in place throughout the life of the program.  See
basis-library/misc/top-level-handler.sml.

In any case, my conclusion is that you have removed the part of
implement-exceptions.fun that installs the toplevel handler (either
directly, or via some optimization in your IL) and you have removed
the basis library code that installs the more sensible handler.

For sanity's sake, if at all possible I would like you to keep the
default toplevel handler, since it prevents this seg fault.

There is probably another bug that is causing the unhandled raise to
happen, but I'm not sure what the cause of that bug is.