Exotic weak hash table & loader problem

[Bike]

There's a problem with weak hash tables and the FASL loader that is too tricky for me to want to solve right this second. I haven't been able to reproduce it except when loading huge FASLs that install things into a weak hash table, so I suspect there's some kind of issue with boehm not tracking references within the loader, somehow?

Anyway, reproduce as follows:

;;;; test.lisp
(in-package #:cl-user)

(macrolet ((sourceinfo ()
             `(funcall #'(setf gethash)
                       ,(ext:current-source-location)
                       ',*symbol*
                       *table*)))
  (sourceinfo))

(macrolet ((defs ()
             `(progn
                ,@(loop repeat 100
                        collect `(defun ,(gensym) ())))))
  (defs))

;;;; REPL
(defparameter *table* (make-hash-table :key #'eq :weakness :key))
(defvar *symbol*)

(with-compilation-unit ()
  (loop for i from 0
        for s being the external-symbols of "CL"
        do (let ((*symbol* s))
             (compile-file "/tmp/test.lisp"
                           :output-file (format nil "/tmp/test~d.fasl" i)
                           :verbose nil :print nil))))

(core:link-fasl-files "/tmp/alltest.fasl"
 (loop for i below 978 collect (format nil "/tmp/test~d.fasl" i)))

(load "/tmp/alltest.fasl")

The idea is to have a bunch of FASLs with intervening init-object-array instructions. I haven't been able to reproduce the problem in a single FASL.

Loading will result in a *table* in which each CL symbol should correspond to a source location, but instead sometimes gets junk from the rest of the FASL, like vectors containing function debug info. The amount of junk varies; I've seen various numbers from 100 to 300 of symbols junked. I haven't tried FASOs yet. This also works with objects other than source locations but I've observed more annoying behavior that way (unbounds and untagged objects rather than vectors).