[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Wierd GC error

Dean_Grannes@MINSK.MT.CS.CMU.EDU writes:
> 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
> [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?
> Thanks,
> ->Dean<-

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.

-William Lott
CMU Common Lisp Group