Steel Bank Common Lisp

backtrace missing one argument for (some?) XEPs

Reported by Nikodemus Siivola on 2008-12-21
2
Affects Status Importance Assigned to Milestone
SBCL
High
Unassigned

Bug Description

Test case:

  (defun foo (x)
    (eval `(/ 1 ,x)))
  (foo 0)

shows

  0: (SB-KERNEL::INTEGER-/-INTEGER 1 0)
  1: ((SB-C::TL-XEP /) 2 1)[:EXTERNAL]

in the backtrace (with *SHOW-ENTRY-POINT-DETAILS*).

Changed in sbcl:
importance: Undecided → Medium
status: New → Confirmed
Nikodemus Siivola (nikodemus) wrote :

Upgrading because I know understand what is going on a bit better: this can lead to important information missing from backtraces.

Following functions demonstrate how file-compiling them will show only the required arguments for their TL-XEPs in the backtrace.

(defun fe0 (&rest rest)
  (let ((* *))
    (apply '/ rest)))

(defun fe1 (x &rest rest)
  (let ((* *))
    (apply '/ x rest)))

(defun fe2 (x y &rest rest)
  (let ((* *))
    (apply '/ x y rest)))

(fe0 10 11 0)

(fe1 10 11 0)

(fe2 10 11 0)

Changed in sbcl:
importance: Medium → High
status: Confirmed → Triaged
Nikodemus Siivola (nikodemus) wrote :

The issue is not file-compilation vs. non-file compilation.

The issue is that MAKE-FUNCTIONAL-FROM-TOPLEVEL-LAMBDA doesn't cross-link the original lambda and the generated XEP and then set the reoptimize flag.

Exactly *why* this generates the behaviour observed is not clear to me yet, but if MAKE-FUNCTIONAL-FROM-TOPLEVEL-LAMBDA is made more isomorphic with MAKE-XEP the issue disappears.

diff --git a/src/compiler/main.lisp b/src/compiler/main.lisp
index c0c6a81..b4258f5 100644
--- a/src/compiler/main.lisp
+++ b/src/compiler/main.lisp
@@ -1115,6 +1115,8 @@ Examples:
       (when name
         (assert-global-function-definition-type name locall-fun))
       (setf (functional-entry-fun fun) locall-fun
+ (functional-entry-fun locall-fun) fun
+ (component-reanalyze component) t
             (functional-kind fun) :external
             (functional-has-external-references-p locall-fun) t
             (functional-has-external-references-p fun) t)

Fixed in my pending tree. Will likely commit after freeze despite imperfect understanding.

Changed in sbcl:
assignee: nobody → Nikodemus Siivola (nikodemus)
status: Triaged → In Progress
Nikodemus Siivola (nikodemus) wrote :

Related to bug 384892. The snippet above is a move in the right direction, but not the whole story. Something is confused here, but it could just be me.

Changed in sbcl:
assignee: Nikodemus Siivola (nikodemus) → nobody
status: In Progress → Triaged
Changed in sbcl:
assignee: nobody → Nikodemus Siivola (nikodemus)
status: Triaged → In Progress
Nikodemus Siivola (nikodemus) wrote :

Attached patch fixes both this and bug 384892.

It also bloats the core by ~2%. At least some of the bloat is due to the cross-compiler getting sloppy due to the patch: for reasons I don't yet understand eg. READ-RIGHT-PAREN is compiled with a non-tail-call, and ends up needing a trap for NIL-FUNCTION-RETURNED.

Nikodemus Siivola (nikodemus) wrote :

In 1.0.44.4.

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.

Other bug subscribers