[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Wierd GC error
> Dear Bugs,
> I just got the following error while compiling:
> * (compile-file "/usr/grannes/tws/new/editor/editor-dialogs")
> Python version 1.0(15e), VM version DECstation 3100/Mach 1.0 on 13 MAR 92 02:5\
> 7:51 pm.
> Compiling: /afs/cs.cmu.edu/project/cmt-5/tws/new/editor/editor-dialogs.lisp 13\
> MAR 92 02:57:35 pm
> Converted EDITOR-DIALOG-HANDLER.
> Compiling DEFUN EDITOR-DIALOG-HANDLER:
> [GC threshold exceeded with 6,590,672 bytes in use. Commencing GC.]
> GC lossage. No transport function for object 0x0b4218b7
> And then the lisp process died. Any ideas?
Basically, something is broken with saving lisp images. The 7 at the
end of 0x0b4218b7 indicates that it is an ``other-pointer.'' All
other pointers are supposed to have a header for the first word that
contains additional type information. If GC couldn't find a transport
function, then this header word must have been corrupted.
The reason why I think the problem is in save-lisp and no in GC in
general is that you guys have reported another save-lisp problem
involving a lisp error to the effect that 0 was an unknown type for an
other pointer. The difference being who found the bogus header first:
a piece of lisp code, or the garbage collector.
Can you supply us with detailed information about how you are building
these lisps? I need to know the number of generations, the options
passed to save-lisp each time, and (if possible) the results of
before and after each save-lisp.
CMU Common Lisp Group