Hi, I gave it some more time today, and found the following. For reference, the CHECK_STRING macro expands to:
do { if(! ((((enum Lisp_Type)(((unsigned long)(string)) & ~(((1UL << ((4 * 8) - 2)) - 1UL) << 2))) == Lisp_Type_Record) && (((unsigned int)(((struct lrecord_header *)((void *)(string)))-> type)) == ((unsigned int)(lrecord_type_string))))) dead_wrong_type_argument(Qstringp, string); } while(0); The check fails in the first part of the above check, where a bitmask is applied to the 'string' variable and checked against Lisp_Type_Record, to see whether it is indeed a Lisp record. The value of the variable 'string' at this point is '0x802b8322', which results in the mask being 2, which is not equal to Lisp_Type_Record. The value at _address_ 0x802b8322, however, is 0x08e00000, which looks much less random and much more like a bitfield to me. I'd say this is a case of confusion between a pointer and its value. (gdb) where #0 0x801397fc in Fintern (string=-2144632030, obarray=-2144627976) at symbols.c:213 #1 0x8013997a in defsymbol (location=0x8028eee4, name=0x8019ede9 "t") at symbols.c:3380 #2 0x80139b12 in init_symbols_once_early () at symbols.c:3292 #3 0x8006b9e6 in xemacs_21_4_21_m68k_unknown_linux (argc=5, argv=0xef82ed54, envp=0xef82ed6c, restart=0) at emacs.c:1333 #4 0x8006c52c in main (argc=5, argv=0xef82ed54, envp=0xef82ed6c) at emacs.c:2829 (gdb) up #1 0x8013997a in defsymbol (location=0x8028eee4, name=0x8019ede9 "t") at symbols.c:3380 3380 *location = Fintern (make_string_nocopy ((const Bufbyte *) name, (gdb) make_string_nocopy starts off with Lisp_String *s; Lisp_Object val; and ends with: XSETSTRING(val, s); return val; XSETSTRING, then, expands to: ((void)((val) = ((Lisp_Object) (s)))); To my untrained eye (at least, untrained in xemacs code), it appears this is where the problem lies: make_string_nocopy creates a pointer to a Lisp_String, which is then cast into a Lisp_String without resolving the pointer first. As a result, the returned Lisp_Object is actually not a Lisp_Object at all, but a pointer to one shoehorned into the data type for a Lisp_Object. Of course, later on, nothing can make sense of that anymore. -- <Lo-lan-do> Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]