Steel Bank Common Lisp

fasl writing fails with "attempt to dump invalid structure"

Reported by Attila Lendvai on 2008-12-21
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
SBCL
Medium
Unassigned

Bug Description

when compiling the attached file i get the attached backtrace:

(compile-file "/tmp/fasl-struct-bug.lisp")

attempt to dump invalid structure:
  #<COMMON-LISP-USER::CLAZZ {1006946AC1}>
How did this happen?

there's some mechanism in the dumper to register "valid" (?) structs in (fasl-output-valid-structures file) when *dump-only-valid-structures* is true. in the example, the macro transforms the literal clos instance created by a reader macro into something else (nil in the minimalistic example). probably due to this the struct is not registered in an earlier phase and the fasl writer errors.

please note that it works as expected in the function body, but no in the default expression of a keyword arg.

Attila Lendvai (attila-lendvai) wrote :
Attila Lendvai (attila-lendvai) wrote :

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

 status confirmed
 importance medium
 tags compiler

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAklN7hIACgkQbSpkIAKPfsVXTwCfSuMCmgo2yjxi1Nd0WQz4eUQf
XMcAnRYQVAzE0Bsb/IwvCH1XnRyZC4I+
=LpgP
-----END PGP SIGNATURE-----

Changed in sbcl:
importance: Undecided → Medium
status: New → Confirmed

This occurs because make-load-form processing (compiler/main.lisp:emit-make-load-form, compiler/ir1tran.lisp:maybe-emit-make-load-forms, possibly compiler/ir1util.lisp:find-constant) is not run on the arglists for function entries and probably should.

It appears that the only place that ir2-component-entries for a component is populated is compiler/entry:entry-analyze. This function calls compiler/entry:compute-entry-info in order to populate the entry-info structure. The following patch appears to fix the problem. However, src/compiler/entry:entry-analyze checks for an existing entry-info structure on each candidate lambda and I am unsure if this is dead code or if there are any consequences to processing a form multiple times with compiler/ir1tran:maybe-make-load-forms.

I should like to commit this at some point in the next week unless someone can tell me why it would be a bad idea to do so.

diff --git a/src/compiler/entry.lisp b/src/compiler/entry.lisp
index ae95297..83d5a00 100644
--- a/src/compiler/entry.lisp
+++ b/src/compiler/entry.lisp
@@ -51,7 +51,12 @@
     (when (policy bind (>= debug 1))
       (let ((args (functional-arg-documentation internal-fun)))
         (aver (not (eq args :unspecified)))
- (setf (entry-info-arguments info) args))
+ (setf (entry-info-arguments info) args)
+ ;; When the component is dumped, the arglists of the entry
+ ;; points will be dumped. If they contain values that need
+ ;; make-load-form processing then we need to do it now (bug
+ ;; 310132).
+ (maybe-emit-make-load-forms args))
       (setf (entry-info-type info) (type-specifier (leaf-type internal-fun)))))
   (values))

Fixed in 1.0.32.26.

Changed in sbcl:
status: Confirmed → Fix Committed
Tobias C. Rittweiler (tcr) wrote :

Isn't this worth one, or two test cases? I wonder how one would best write test cases
involving the file-compiler. We really ough to have a COMPILE-FROM-STREAM which
has file-compilation semantics!

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