Steel Bank Common Lisp

DEBUG-SOURCE wrong when debugging lambdas defined from the REPL

Reported by Elias Martenson on 2012-01-27
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
SBCL
Medium
Unassigned

Bug Description

With SBCL 1.0.55, run the following from the REPL:

(locally (declare (optimize (speed 0) (safety 3) (debug 3)))
             (let ((f #'(lambda (x cont)
                      (print x)
                      (if (zerop x)
                          (error "foo")
                          (funcall cont (1- x) cont)))))
           (funcall f 10 f)))

The result from SBCL is:

debugger invoked on a SIMPLE-ERROR in thread
#<THREAD "initial thread" RUNNING {1002991073}>:
  foo

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [ABORT] Exit debugger, returning to top level.

((LAMBDA (X CONT)) 0 #<FUNCTION (LAMBDA #) {1004619DCB}>)
source:
error finding source: Don't know how to use a DEBUG-SOURCE without a namestring or a form.
                      This is probably a bug in SBCL itself. (Alternatively,
                      SBCL might have been corrupted by bad user code, e.g. by
                      an undefined Lisp operation like (FMAKUNBOUND 'COMPILE),
                      or by stray pointers from alien code or from unsafe Lisp
                      code; or there might be a bug in the OS or hardware that
                      SBCL is running on.) If it seems to be a bug in SBCL
                      itself, the maintainers would like to know about it. Bug
                      reports are welcome on the SBCL mailing lists, which you
                      can find at <http://sbcl.sourceforge.net/>.

Changed in sbcl:
status: New → In Progress
assignee: nobody → Nikodemus Siivola (nikodemus)
importance: Undecided → Medium
Nikodemus Siivola (nikodemus) wrote :

commit 04a651e749befd65ffd8bf49f689b6e7d55607e2
Author: Nikodemus Siivola <email address hidden>
Date: Thu May 17 15:22:22 2012 +0300

    fix source information for functions from EVAL

     * Removed the breathtaking (NAMED-LAMBDA (EVAL (DEFUN FOO)) ...) hack, which
       caused inconsistent source locations, and broke the built-in debugger
       source command for evaluated functions.

       Replace it with *SOURCE-FORM-CONTEXT-ALIST*, which allows the simple
       evaluator to communicate the original context to the compiler without
       messing with the function source.

       This also means we no longer have to wrap named-lambdas and lambdas in
       another lambda, but can instead compile them directly -- which in turn
       allows FUNCTION-LAMBDA-EXPRESSION to work correctly for definitions from
       EVAL and LOAD.

     * Additionally, use a handler to muffle any compiler notes from EVAL instead
       of using a declaration: those can leak to the user via F-L-E.

     * Change ACTUALLY-COMPILE to return a function signaling an error instead of
       returning NIL when compilation fails fatally. Doing this in
       ACTUALLY-COMPILE allows us to rely on COMPILE-IN-LEXENV always returning a
       function, and gives easy access to a better error message.

     * Properly associate COMPILER-ERRORS with their SIGNAL-ERROR restart.

     * Adjust debug.impure.lisp to be less dependent on the details of
       %SIMPLE-EVAL.

     * Test cases. Pay special attention to TEST-DEBUGGER in debug.impure.lisp.

     * New docstring for COMPILE. Added a sneaky teaser about COMPILE being able
       to recompile things, which is new starting to look feasible.

Changed in sbcl:
assignee: Nikodemus Siivola (nikodemus) → nobody
status: In Progress → Fix Committed
Changed in sbcl:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers