[ clisp-Bugs-1220548 ] unwind-protect confuses abort restart

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Bugs item #1220548, was opened at 2005-06-14 12:36
Message generated for change (Comment added) made by sds
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1220548&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jörg Höhle (hoehle)
Assigned to: Nobody/Anonymous (nobody)
Summary: unwind-protect confuses abort restart

Initial Comment:
Hi,

I mentioned that in clisp-devel around October 2004
["confused debugger, aborts to outer break level --
repeatable"], but did not submit a bug report. The bug
is still in clisp-cvs.

When there's an unwind-protect frame somewhere on the
stack, restarts may get confused. As a result, Lisp
sessions get mixed up (e.g. today it affected my SLIME
session).
I originally noticed this with cl-sql, which uses
with-foreign-string, which does the same as unwind-protect.

[17]> (unwind-protect (error "hi") (print "out"))
*** - hi
Mche Optionen:
ABORT          :R1      ABORT
Break 1 [18]> (unwind-protect (error "hi") (print "out"))
*** - hi
Mche Optionen:
ABORT          :R1      ABORT
ABORT          :R2      ABORT
Break 2 [19]> abort
"out" 
"out" 
[20]>
Failed Expectation: get out only one level. The :r1
restart does this correctly.

In contrast, using the :r1 restarts gets out only one
level, as expected.
This also happens using the interpreted memory image.

Regards,
 JH

----------------------------------------------------------------------

>Comment By: Sam Steingold (sds)
Date: 2008-01-07 01:11

Message:
Logged In: YES 
user_id=5735
Originator: NO

now that I fixed the quit debugger command - 1448744 - maybe you could
re-investigate this bug?

----------------------------------------------------------------------

Comment By: Jörg Höhle (hoehle)
Date: 2006-03-17 03:21

Message:
Logged In: YES 
user_id=377168

The bug is still there. I noticed it again while
investigating the SP stack overflow and :q issues.

Break 2 [4]> abort
leads to a call to reset() with a messed up count argument
Breakpoint 2, reset (count=1) at eval.d:511
(gdb) cont
Breakpoint 2, reset (count=3081360032) at eval.d:511
The result is an abort to the outermost level, instead of to
the next one.

----------------------------------------------------------------------

Comment By: Sam Steingold (sds)
Date: 2005-06-21 13:23

Message:
Logged In: YES 
user_id=5735

note that there is an "abort" restart and an "abort" command.
"abort" command is the same as "unwind" 
(which does what it should - unwind 1 level up).
see debug.d

----------------------------------------------------------------------

Comment By: Jörg Höhle (hoehle)
Date: 2005-06-21 04:10

Message:
Logged In: YES 
user_id=377168

I also looked at reploop.lisp and found no obvious bug.
Still, the observable behaviour is unsound, cannot be
understood and cannot be explained to a user.
CLISP-2.28 works fine. Neither do clisp-2.33, nor 2.33.2,
nor CVS.

In the first example below, the outermost restart named
ABORT is chosen. In the second example, it's the innermost
one. Where's the explanation that one can understand so as
to predict the system's behaviour?

[1]> (print(unwind-protect(break"hi")(print"uh")))
** - Continuable Error
hi
Wenn Sie (mit Continue) fortfahren: BREAK-Schleife beenden.
Break 1 [2]> (print(unwind-protect(break"hi")(print"uh")))
** - Continuable Error
hi
Wenn Sie (mit Continue) fortfahren: BREAK-Schleife beenden.
Break 2 [3]> (print(unwind-protect(break"hi")(print"uh")))
** - Continuable Error
hi
Wenn Sie (mit Continue) fortfahren: BREAK-Schleife beenden.
Break 3 [4]> abort
"uh"
"uh"
"uh"
[5]> 
-- abort behaves like :q, but that's not how its documented.
The user sees 3 restarts named ABORT and observes that the
latter, not the former one is used, contrary to all
documentation and expectations.

[5]> (print(with-simple-restart(abort"foo")(break"hi")))
** - Continuable Error
hi
Wenn Sie (mit Continue) fortfahren: BREAK-Schleife beenden.
Weitere mche Optionen:
ABORT          :R1      foo
Break 1 [6]> (print(with-simple-restart(abort"foo")(break"hi")))
** - Continuable Error
hi
Wenn Sie (mit Continue) fortfahren: BREAK-Schleife beenden.
Weitere mche Optionen:
ABORT          :R1      foo
ABORT          :R2      foo
Break 2 [7]> (print(with-simple-restart(abort"foo")(break"hi")))
** - Continuable Error
hi
Wenn Sie (mit Continue) fortfahren: BREAK-Schleife beenden.
Weitere mche Optionen:
ABORT          :R1      foo
ABORT          :R2      foo
ABORT          :R3      foo
Break 3 [8]> abort
Break 2 [7]> abort
Break 1 [6]> abort
[9]> 
Here, clisp meets the user's expectations. Levels nest
correctly.

Note that clisp-2.33 showed 6 restarts in the latter case:
ABORT          :R1      foo
ABORT          :R2      ABORT -- [to top-level]
ABORT          :R3      foo
ABORT          :R4      ABORT  [--to top-level]
ABORT          :R5      foo
ABORT          :R6      ABORT   [--to top-level]
Yet it had similar broken behaviour.

----------------------------------------------------------------------

Comment By: Sam Steingold (sds)
Date: 2005-06-20 13:20

Message:
Logged In: YES 
user_id=5735

new restart is bound by pushing the object on *active-restarts*.
search for applicable restarts in reploop.lisp is done 
by compute-restarts from the start of *active-restarts*, 
i.e., from the most recent bindings.
this search is affected by applicable-restart-p
which checks the current condition.
in short, the system is non-trivial but reasonable and
compliant.

----------------------------------------------------------------------

Comment By: Jörg Höhle (hoehle)
Date: 2005-06-20 12:56

Message:
Logged In: YES 
user_id=377168

I had hoped my examples demonstrate that a restart named
ABORT behaves differently than other names, for no apparent
reason. This is very confusing to users, causing trouble in
the REPL which even lead to CLISP quitting a SLIME session
(and exiting).

Please explain "closest to your stack frame": while
navigating the stack with up and down commands, I did not
observe that the restarts would vary according to the
current position.

Furthermore, repeating the exercise with 3 times
(unwind-protect (error "hi")(print "uh"))
shows that it's the outermost ABORT restart (it's not even
skipping one to the second) that's choosen! I.e. CLISP seems
to choose the last restart, not the first one (while other
names lead to the expected behaviour).

----------------------------------------------------------------------

Comment By: Sam Steingold (sds)
Date: 2005-06-14 16:53

Message:
Logged In: YES 
user_id=5735

when there are several identically named restarts available,
one should use the ":R*" command to ensure the right one.
if you use the restart name, the first (closest to your
current frame)
restart is invoked, and it may take you up the stack 
beyond your other restarts with the same name.
see condition.lisp (*active-restarts* &c)

----------------------------------------------------------------------

Comment By: Jörg Höhle (hoehle)
Date: 2005-06-14 12:52

Message:
Logged In: YES 
user_id=377168

It seems like the topmost 'abort restart is sometimes
skipped, as the following shows:
[60]> (with-simple-restart (foo "my foo restart")
(print(break)))
1. Trace: (SYSTEM::BREAK-LOOP 'NIL '#<SIMPLE-CONDITION
#x2042A01E> 'T)
** - Continuable Error
Break
Wenn Sie (mit Continue) fortfahren: BREAK-Schleife beenden.
Weitere mche Optionen:
FOO            :R1      my foo restart
ABORT          :R2      ABORT
Break 1 [61]> (with-simple-restart (abort "my foo restart")
(print(break)))
2. Trace: (SYSTEM::BREAK-LOOP 'NIL '#<SIMPLE-CONDITION
#x2042EE46> 'T)
** - Continuable Error
Break
Wenn Sie (mit Continue) fortfahren: BREAK-Schleife beenden.
Weitere mche Optionen:
ABORT          :R1      my foo restart
ABORT          :R2      ABORT
FOO            :R3      my foo restart
ABORT          :R4      ABORT
Break 2 [62]> abort
Break 1 [61]> abort ; --- this prompt shows that "my foo
restart" was not invoked
[63]> (with-simple-restart (foo "my foo restart")
(print(break)))
1. Trace: (SYSTEM::BREAK-LOOP 'NIL '#<SIMPLE-CONDITION
#x204353E6> 'T)
** - Continuable Error
Break
Wenn Sie (mit Continue) fortfahren: BREAK-Schleife beenden.
Weitere mche Optionen:
FOO            :R1      my foo restart
ABORT          :R2      ABORT
Break 1 [64]> foo
NIL ;
T ; --- here my foo restart was invoked
[65]> 

Maybe this has to do with the ANSI-CL / Paul Dietz'
testsuite related change that always supplies an abort
restart in the repl? cf. Changelog 2004-02-25?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1220548&group_id=1355