losing with newly released STRING ?

[Jon L White <JONL at MIT-MC>]

    Date: 9 November 1981 01:53-EST
    From: George J. Carrette <GJC at MIT-MC>
    After enough consing/garbage-collection the pnames of strings change.
    ...
    ;; note the value of the following variable
    STATUS-SSTATUS-FUNCTION-ALIST
    ;; then compile a file
    (comfile "jl;emacs")
    . . . 
This problem may not be related particularly to the new STRING, but
possibly to the dynamics of GC/consing -- your dumped VASL is already 
garbaged, before you ever start to do COMFILE.  The point at which you 
noticed the bug occurred while trying to make a FORMAT string, and I 
noticed that the GC-DAEMON in VASL is backwards (in a sense) -- by not 
loading the Baker GCDEMN file "early" (i.e., before the STRING file) its 
daemon function gets run before the string gc-daemon function, and if it 
causes any consing, there could be some lossages.  I'll change the Baker 
GCDEMN file to run its function 'last', rather than first.

But where did this value for STATUS-SSTATUS-FUNCTION-ALIST
get created?  None of the strings on it are "real", which is why
they go away after the first STRING-GC; but the string GC markarray
has entries for lots of other STATUS/SSTATUS keyword names which
aren't on that list.  Could you make up a new VASL with the to-be-fixed
Baker GCDEMN, and with the current STRING, but having first done 
(SETQ STR:GC-CHECK? 'T) ?  
If there are any truly weird conditions occuring during the load-up 
phase, this should catch them (but it also may catch a legitimate 
situation where queue-ing up of interrupts had occurred).