heap dumping breaks eq? and eqv? hashtables

[will]

When a heap image is dumped, hashtables that were created by make-eq-hashtable or make-eqv-hashtable will contain timestamps relative to the gc counters of the session that dumped the heap. When the heap image is used to start a subsequent session, the gc counters start again from 0, causing the dumped hashtables to operate incorrectly. Fortunately, they are likely to fail with the following error:

Error: assertion failure:  (< t0 (gc-counter))

I think the right way to fix this is for the heap dumping procedures to find all of the problematic hashtables (using sro as in the code below) and tell them to reset themselves to a dumpable state.

In the short term, however, the only workaround is to avoid dumping any eq? or eqv? hashtables. The following procedure will find any of the problematic hashtables that are currently alive in the system, and will print a vector of their keys.

(define (report-on-problematic-hashtables)
  (let* ((record-like-objects (sro 3 5 -1))
         (hashtables
          (filter hashtable? (vector->list record-like-objects)))
         (problematic-hashtables
          (filter (lambda (ht) (not (hashtable-hash-function ht)))
                  hashtables)))
    (if (null? problematic-hashtables)
        (begin (display "No problematic hashtables were found.")
               (newline))
        (for-each (lambda (ht)
                    (display "Problematic hashtable found.")
                    (newline)
                    (display (hashtable-size ht))
                    (display " entries with keys:")
                    (newline)
                    (write (hashtable-keys ht))
                    (newline))
                  problematic-hashtables))))

[pnkfelix]

another potential fix would be to dump (and subsequently load) the gc counter as part of the heap image. But this may introduce other problems; Will's proposed fix is more certain to be correct and may even be easier to implement.