HELP! (need debugging advice) [was: crash while loading XML file]

Stephen> It's an XEmacs core bug. The bytecode interpreter is Stephen> somehow corrupting the compiled bytecode in a Stephen> post-optimizing stage, and the interpreter "falls off the Stephen> end" of the code and tries to execute the string Stephen> terminating NUL, which is not a legal bytecode. OK, I've got this partially analyzed. XEmacs makes an opaque object to contain the bytecode, specifies the size correctly[1] as far as I can tell, the optimized code gets put into place correctly, but later (before the code is actually executed) malloc proceeds to tromp on the last 4 bytes of the space used by the bytecode. How do I go about finding out what _malloc_ thinks it has allocated here? And why would malloc make this kind of mistake? Alternatively, if you want to look at it yourself, (1) start gdb, and load in a 21.4 XEmacs (don't start it yet) (2) make sure Martin's debugger commands are loaded (source src/.gdbinit) (3) define an convenience command define cnp continue pobj constants pobj $.contents[0] end (4) run -vanilla (5) type (setq user-mail-address "nobody(a)nowhere.none") RET (6) then C-x C-f no-such-file.xml [NB, no RET yet!] (7) set a breakpoint at optimize_byte_code -- continue, and _now_ type RET to xemacs (8) use cnp to fast forward until it prints the symbol-name `sgml-xml-p' (you may get a warning message the first time because gdb stops twice at signals, you can ignore it) -- about 40 reps; starting with "continue 35" ought to be safe, too. (9) use "finish" twice, then "pobj fun", then "pobj $.instructions", then "watch $.data[88]" (10) disable the breakpoint at optimize_byte_code, continue, and watch make_general_lisp_hash_table tromp on the watchpoint. (IIRC if you set a breakpoint at make_general_lisp_hash_table and step through the process, you can see that it's actually malloc that does the evil deed.) The pobj constants, pobj $.contents[N] is a useful trick to get a hint as to which Lisp function is being executed. Footnotes: [1] Assuming that ALIGNOF(max_align_t) == 4 on the Intel platform. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN My nostalgia for Icon makes me forget about any of the bad things. I don't have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py