[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
losing with newly released STRING ?
- To: GJC at MIT-MC
- Subject: losing with newly released STRING ?
- From: Jon L White <JONL at MIT-MC>
- Date: Mon, 9 Nov 81 21:09:00 GMT
- Cc: BUG-LISP at MIT-MC
- Original-date: 9 November 1981 16:09-EST
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
;; then compile a file
. . .
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).