| Hugs Version: May 1999
| Configuration options: none (defaults)
| Operating System: Windows NT 4.0 SP 3
| Compiler: N/A; using the precompiled executable hugs.exe from
| http://www.cse.ogi.edu/~mpj/Hugs98/win32exes.zip
|
| Expected the Hugs interpreter to catch any run-time error, provide a
| message, and return to the interpreter prompt.
|
| Observed behavior: Crash terminates Hugs.
|
| Source file, hugsbug.hs, 2 lines:
| f :: () -> ((), ())
| f d = let (d', _) = (d, ()) in f d'
This is an interesting example. The crash occurs during garbage
collection, and does not reflect any run-time error in your code.
If I'm correct, it occurs because the laziness in the definition
of f allows it to build up a large, unevaluated graph structure,
that causes the C stack to overflow when it tries to traverse it,
recursively, during garbage collection. Unfortunately, there
doesn't seem to be a portable way to catch C stack overflow (nor
is there much that we could do about it in this case if we could
catch it, except perhaps to print a better error message before
the interpreter terminates). You don't see this kind of behavior
often because the garbage collector only uses recursive calls to
traverse the left spines of an expression, using iteration instead
to move down to the right. (I'm think of the graph structures, and,
in particular, the pair values, that are used in the underlying
implementation if that wasn't already clear!) We might be able to
fix this by changing the garbage collector to use a pointer reversal
technique. In any case, it won't be a problem when the new STG Hugs
comes on line. In the meantime, assuming that your code was distilled
from a longer example that you need to get working right now, my
best advice for a work-around would be to look for ways to add a little
strictness so that you don't build up a large unevaluated data
structure. For the example above, replacing f d' with f $! d' has
the desired effect.
Hope this helps,
Mark
