exit & dynamic wind

exit & dynamic wind

[Ian Price]

Hey guilers,

If you run (exit) at the repl, it is caught, and any after-thunks from
dynamic-wind will be called when you continue with ,q . However, in a
guile script, it is not an error, and the after-thunks are not
called.

$ cat Desktop/dynamic-wind-test.ss
#!r6rs
(import (rnrs))

(dynamic-wind
  (lambda () #f)
  (lambda () (exit 0))
  (lambda () (display "Exiting dynamic wind...\n")))
$ ikarus --r6rs-script Desktop/dynamic-wind-test.ss
$ mosh Desktop/dynamic-wind-test.ss
$ larceny -r6rs -program Desktop/dynamic-wind-test.ss
$ guile -s Desktop/dynamic-wind-test.ss
$ racket --script Desktop/dynamic-wind-test.ss
$ guile
GNU Guile 2.0.0.119-95c1c
Copyright (C) 1995-2011 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> (dynamic-wind
  (lambda () #f)
  (lambda () (exit 0))
  (lambda () (display "Exiting dynamic wind...\n")))
<unnamed port>:2:13: In procedure #<procedure a46e9b0 at <current
input>:1:0 ()>:
<unnamed port>:2:13: Throw to key `quit' with args `(0)'.

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
scheme@(guile-user) [1]> ,q
Exiting dynamic wind...

What I think should probably happen, is that the (exit) should not be
caught at the repl, but that the after thunks should be called in both
cases (but not if you used primitive-exit or similar). As you can see
from the transcript, this is not the popular choice among scheme
implementers ;).

Thanks,
Ian

Re: exit & dynamic wind

[Andy Wingo]

On Tue 22 Mar 2011 14:26, Ian Price <ianprice90@googlemail.com> writes:

> If you run (exit) at the repl, it is caught, and any after-thunks from
> dynamic-wind will be called when you continue with ,q . However, in a
> guile script, it is not an error, and the after-thunks are not
> called.

I have tracked this down and it seems that this was the case in 1.8 as
well.

The issue is that when you run a script, the default catch-all ends up
being provided by scm_c_with_continuation_barrier.  This procedure uses
scm_handle_by_message_noexit as the pre-unwind handler, and that
procedure in turn does an `exit' if the key is `quit'.

However this sounds bogus to me: usually you would want to unwind.
Furthermore you probably want to print the message using the ports that
were current at the time of the with-continuation-barrier, not the
throw.

This change first appeared in 43e01b1ee350c823505d1397a306c8e1bfa31469,
in 2006, and appears to be a misunderstanding.

I have pushed something that causes the stack to be unwound before
exiting.  Please let me know if you still see problems.

Thanks,

Andy
-- 
http://wingolog.org/

Re: exit & dynamic wind

[Neil Jerram]

Andy Wingo <wingo@pobox.com> writes:

> I have pushed something that causes the stack to be unwound before
> exiting.  Please let me know if you still see problems.

Unfortunately, yes.  Now when snarf-check-and-output-texi is run, I see:

|   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>)))

Reverting ecba00af6501e082b86c8f2f7730081c733509d7 fixes this again.

Or, perhaps, "hides the problem" again.  It could be that there is a
real problem in snarf-check-and-output-texi that was being hidden by the
failure to unwind.

       Neil

Re: exit & dynamic wind

[Andy Wingo]

On Fri 25 Mar 2011 02:52, Neil Jerram <neil@ossau.uklinux.net> writes:

> Andy Wingo <wingo@pobox.com> writes:
>
>> I have pushed something that causes the stack to be unwound before
>> exiting.  Please let me know if you still see problems.
>
> Unfortunately, yes.  Now when snarf-check-and-output-texi is run, I see:
>
> |   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>)))
>
> Reverting ecba00af6501e082b86c8f2f7730081c733509d7 fixes this again.

I reverted that patch, it was poorly considered.  (Before, that code
would print a backtrace in some cases, which was a good thing.)  Thanks
for the note.

Andy
-- 
http://wingolog.org/

Re: exit & dynamic wind

[Andy Wingo]

Hello!

On Fri 25 Mar 2011 17:45, Andy Wingo <wingo@pobox.com> writes:

> On Fri 25 Mar 2011 02:52, Neil Jerram <neil@ossau.uklinux.net> writes:
>
>> Andy Wingo <wingo@pobox.com> writes:
>>
>>> I have pushed something that causes the stack to be unwound before
>>> exiting.
>>
>> |   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.

>> Reverting ecba00af6501e082b86c8f2f7730081c733509d7 fixes this again.
>
> I reverted that patch, it was poorly considered.  (Before, that code
> would print a backtrace in some cases, which was a good thing.)

I have reapplied it with modifications: now, the exception and backtrace
are printed before unwinding.  The exit() happens after unwinding.

Happy hacking!

Andy
-- 
http://wingolog.org/

Re: exit & dynamic wind

[Neil Jerram]

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?

      Neil

Re: exit & dynamic wind

[Mike Gran]

----- Original Message -----
> From:Neil Jerram <neil@ossau.uklinux.net>
> To:Andy Wingo <wingo@pobox.com>
> Cc:bug-guile@gnu.org; Ian Price <ianprice90@googlemail.com>; guile-devel <guile-devel@gnu.org>
> Sent:Wednesday, March 30, 2011 11:31 AM
> Subject:Re: exit & dynamic wind
> 
> 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?

This likely closes out bug 32340, by the way.

-Mike

Re: exit & dynamic wind

[Andy Wingo]

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/

Re: exit & dynamic wind

[Andy Wingo]

On Wed 30 Mar 2011 21:06, Mike Gran <spk121@yahoo.com> writes:

> ----- Original Message -----
>> From:Neil Jerram <neil@ossau.uklinux.net>
>> To:Andy Wingo <wingo@pobox.com>
>> Cc:bug-guile@gnu.org; Ian Price <ianprice90@googlemail.com>; guile-devel <guile-devel@gnu.org>
>> Sent:Wednesday, March 30, 2011 11:31 AM
>> Subject:Re: exit & dynamic wind
>> 
>> 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?
>
> This likely closes out bug 32340, by the way.

Interesting!  Thanks for the cross-link; closed that bug.  It probably
is indeed the same thing.

Andy
-- 
http://wingolog.org/

Re: exit & dynamic wind

[Andy Wingo]

On Wed 30 Mar 2011 23:25, Andy Wingo <wingo@pobox.com> writes:

> 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.

Sorry, forgot to mention something else.  ensure-writable-dir caused the
build to see these errors.  The patch under consideration -- allowing
the stack to unwind during a throw to `quit' -- also exercised this
case.  I didn't understand it at the time, so I reverted and moved on.
But then the ensure-writable-dir thing brought up the issue again, so
thence the fix, so thence the ability to unwind the stack on a throw to
`quit', even before eval.scm is compiled.

This probably still isn't clear; please ask if you have more questions!

Andy
-- 
http://wingolog.org/

Re: exit & dynamic wind

[Neil Jerram]

Andy Wingo <wingo@pobox.com> writes:

> 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,

i.e. SCM_VM_DATA (vm), I presume

> it was looking
> for it at the VM's stack-pointer as seen when the prompt was created
> --

i.e. SCM_PROMPT_REGISTERS (prompt)

> 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 :)

It certainly does, thank you!

       Neil