Re: exit & dynamic wind

[Andy Wingo <wingo@pobox.com>]

On Wed 30 Mar 2011 20:31, Neil Jerram <neil@ossau.uklinux.net> writes:

> Andy Wingo <wingo@pobox.com> writes:
>
>>>> |   GEN    guile-procedures.texi
>>>> | guile: uncaught throw to wrong-type-arg: (#f Wrong type (expecting ~A): ~S (exact integer (#t #<catch-closure 9916c10> #<catch-closure 9916be0>)) ((#t #<catch-closure 9916c10> #<catch-closure 9916be0>)))
>>
>> This, it turns out, was something more pernicious, fixed in
>> 572eef50c2d902d34427945dd504ba03af666e48.
>
> Thanks for the fix.  I'm afraid I struggled to understand the change,
> though - although I admit it may be largely my fault, as I'm not up to
> speed with VM or prompt internals.  Nevertheless, would it perhaps be
> worth a bit more commenting or a test, for future readers?

As for explanations... Catch and throw are implemented using fluids and
prompt and abort.  (A discussion of that is here:
http://wingolog.org/archives/2010/02/14/sidelong-glimpses .)  An abort
can pass arguments to the prompt's abort handler.  It does so by pushing
those values and a number-of-values marker onto the Scheme stack, after
the Scheme and dynamic stacks are unwound to the prompt.  The prompt
then needs to pop off those values and pass them to the handler.

It so happens that this values-then-number-of-values convention is the
same convention as is used for multiple-value returns -- so for compiled
code what happens is that the compiler inlines the handler, and the VM
just does a multiple-value bind on the values from the stack.  (See
truncate-values in the VM instruction docs.)

That's what happens when `prompt' is compiled, as it is in eval.scm.
But before eval.scm is compiled, we use eval.c, which also has to have
support for prompt and abort; but it's necessarily a different
mechanism.  This commit fixed a bug in that mechanism: that instead of
looking for the number-of-values marker (the exact integer that it was
expecting) from the VM's stack, as unwound by the abort, it was looking
for it at the VM's stack-pointer as seen when the prompt was created --
which necessarily is below any values returned to the prompt's abort
handler.

We didn't see this issue before because compiling eval.scm did not cause
a `throw'.  Interesting, no?  But since I changed the implementation of
ensure-writable-dir to one that probably throws, we see this error.

Any other error that caused a `throw' to a `catch' to occur before
eval.scm was compiled probably caused this error in the past.  I don't
know if we had any reports of it; I wouldn't be surprised.  In any case,
a tricky bug, and a good one to have fixed.

We do have prompt and abort tests for the VM implementation.  We don't
run them with the boot evaluator, because we can't, not after eval.scm
is compiled -- and anyway, now compilation causes throws at times, so
we'll pick up these issues from users if it comes back.

Hope that explains things :)

Andy
-- 
http://wingolog.org/