[armedbear-devel] Serious bug involving UWP
Mark Evenson
evenson at panix.com
Thu Sep 17 11:44:13 UTC 2009
On 9/17/09 10:56 AM, Tobias C. Rittweiler wrote:
> C-c C-c is SWANK-COMPILE-STRING in swank-abcl.lisp.
>
> If you follow the control flow, you'll see that in SLDB-LOOP (we come
> here through *DEBUGGER-HOOK*) in swank.lisp,
>
> __the UNWINDED-PROTECT's protected form is *never* executed and it goes
> straight to the cleanup forms.__
Hmmm, I don't come up with the same analysis of the control flow. I
don't see the code going through SLDB-LOOP at all, but rather bombing
out in swank-abcl.lisp's implementation of SWANK-COMPILE-STRING at line
396 because in ABCL the comma not inside a backquote is a READER-ERROR
which is not a subtype of the WARNING referenced in the enclosing
HANDLER-BIND. The actual error is coming from READ-FROM-STRING:
(defimplementation swank-compile-string (string &key buffer position
filename
policy)
(declare (ignore filename policy))
(let ((jvm::*resignal-compiler-warnings* t)
(*abcl-signaled-conditions* nil))
(handler-bind ((warning #'handle-compiler-warning))
(let ((*buffer-name* buffer)
(*buffer-start-position* position)
(*buffer-string* string))
(funcall (compile nil (read-from-string
(format nil "(~S () ~A)" 'lambda string))))
t))))
One can reproduce the error from the SLIME REPL by evaluating
(SWANK-BACKEND:SWANK-COMPILE-STRING "(defun test (x) ,bar)" :BUFFER
"*slime-scratch*" :POSITION 1 :FILENAME NIL :POLICY NIL)
If I bind a handler for ERROR in the enclosing HANDLER-BIND, I do trap
the error.
Tobias: are you relying on visual inspection of the problem here, or
are you getting a backtrace somehow? I didn't understand your comment
"(we come here through *DEBUGGER-HOOK*)".
SBCL writes the string to a temporary file, then compiles that file.
Since the ABCL code for compiling a file works ok, I would maybe pursue
that route.
--
"A screaming comes across the sky. It has happened before, but there
is nothing to compare to it now."
More information about the armedbear-devel
mailing list