Line 3186 is correct; sorry for the confusion. I am running whatever is in CVS as of 2:45 pm (PST) on 3/10. Also, you're right about pobj not understanding lrecords. In addition, without --gung-ho, marking a lrecord increments the pointer to the implementation held in the lrecord. Now onto today's debugging: I updated this morning, and re-built with debugging, no optimization, and without --gung-ho. See the attached stack trace for reference (this is from running "xemacs -q" under GDB). It looks like marking *(staticvec[1]) is where the crash is occuring (frame 5). This object is a Lisp_Vector with 16411 elements in it. Position 2753 is the symbol text-mode-symbol-table. All of the ASCII characters have been marked. Marking the 1th (that is, second) element of ct->level1[] is where the crash is occuring; "pobj" says: (struct Lisp_String *) 0x490400 {_size = 0, _data = 0x4e5000 "", plist = 3660} But, we end up in the Lisp_Type_Record section of mark_object() and crash. -lipp ps: Please note, configure'ing with --gung-ho fixes this problem. -----Original Message----- From: Gunnar Evermann [mailto:ge204＠eng.cam.ac.uk] Sent: Tuesday, March 09, 1999 4:54 PM To: XEmacs Developers Subject: Re: Argh! What am I missing with MULE build? (21.0-b64 + Solaris 2.5 .1 + EGCS 1.1.1) Damon Lipparelli <lipp(a)primus.com&gt; writes: called. *(staticvec[0]). I assume you mean line 3186? Which version of alloc.c are you using anyway? The line numbers in your backtrace look like the latest one from CVS, i.e. including Martin's patch after 21.0-b65? I am afraid I just realized that the gdb commands cannot currently handle marked lrecords properly (at least for !USE_INDEXED_LRECORD_IMPLEMENTATION), so if you mean by 'corrupted' that pobj say 'unknown Lisp_Object' then that is expected :-( I noted below the following line numbers what kind of object is about to be marked at each point in your backtrace: <mark_object>) Lisp_Type_Record marker function Lisp_Type_symbol sym->value Lisp_Type_Vector element i staticvec[i] If I read this right we're trying to mark a chartable which is the value of a symbol which is an element of a Vector which is staticpro'd. Could you check what this vector contains? possibly before the actual marking? Presumably it is already corrupted before the GC -- do you always get the crash on marking this particular vector? Then you might want to try the watchpoint or always_gc stuff Martin mentioned... FWIW I have an additional report of such a crash under 21.0b65... -- Gunnar Evermann Speech, Vision & Robotics Group Engineering Department Cambridge University