Re: [Bug: 21.5-b11] assertion failed

Thanks for the report. I don't know what is causing these, but I just saw one, too. Pete> I was editing a Perl file. I clicked on a tab to switch to Pete> another Perl bufer, and XEmacs crashed. I couldn't repeat Pete> it. On standard out, I got I don't think Perl has anything to do with it, it's native widgets, I think (I see them sporadically in customize buffers and a local library I have that uses native widgets via widget.el, always when clicking on something). Pete> Fatal error: assertion failed, file gui-x.c, line 284, Pete> RECORD_TYPEP (obj, lrecord_type_cons) Pete> I ran gdb as htese instructions recommend, and got [4 uninteresting frames elided] Pete> #5 0x9c5a4 in zero_out_command_line_status_vars () at emacs.c:4283 You only got 5 frames of backtrace? Urk. If you go up a few frames (gdb command is "up" oddly enough ;-), and do (gdb) print * (struct lrecord_header *) client_data $5 = {type = 63, mark = 0, c_readonly = 1, lisp_readonly = 1, unused = 1824183} (gdb) print (enum lrecord_type) lrecord_type_free + 0 $11 = 63 Suspicious, huh? I'd be interested to know what the type member is in your crash. The fact that I got "free" suggests uninitialized data somewhere, but if your stack was smashed (as the small number of frames suggests), then that could just be a random number. If you get a different number, you can just report it, but if you're curious the list of types is in enum lrecord_type in src/lrecord.h. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.