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]
