[Bug: 21.4.22] Sporadic crash entering a group with Gnus
David S. Goldberg writes:
That's quite an impressive list of shadows you have there. It
probably doesn't matter to this bug, but sometimes mixing versions can
cause problems. And heaven help you if there are any .elcs compiled
with Gnu Emacs; all bets are off in that case. I don't think /afs is
one of the standard places we look, so that's presumably a local
configuration that you could undo (the packages you have installed in
.xemacs will shadow them).
----------------------------------------------------------------------
blackbird!dsg$ Fatal error: assertion failed, file bytecode.c, line 1479, ABORT()
That's the unknown opcode abort. If you can find a reliable recipe to
reproduce this, you can have the keys to the kingdom.
There are two ways to get here. One is to have Some Other Emacs's
bytecode get mixed in. (This is how .elcs compiled by GNU Emacs can
crash us.) If that's it, then perhaps cleaning up your load path will
fix this. The other seems to be a miscalculation of the bytecode
interpreter stack space needed for some operation or other. That's
the one that we would dearly love to fix.
# bind (form)
gnus-byte-compile((lambda nil (cond (... ...) (... ...) (... ...) (uncached ...) (...
...) (... ...) (... ...) (... ...) (... ...) (... ...) (... ...) (... ...) (... ...) (...
...) (... ...) (t ...))))
Aha! This one you can work around, I think. There's a variable
`gnus-use-byte-compile'; if you set that to nil, this crash won't
occur.
Do you have any customizations of `gnus-summary-highlight'?
I don't know how to do it offhand, but it might be possible to get a
look at that form that's being compiled. Would you be willing to run
XEmacs under the debugger until you get a crash, *if* I can figure out
how to print the value of that form being compiled? (No need to do it
yet, since I don't know yet for sure it's possible.) Hmm; maybe we
can get it here?
#7 0x000000000045b66f in execute_optimized_program (
program=<value optimized out>, stack_depth=<value optimized out>,
constants_data=0x254ed60) at bytecode.c:658
Oh, thank you GCC. I'd like to see that stack_depth, and program....
#8 0x000000000045cf47 in funcall_compiled_function (fun=39408616,
nargs=1,
args=0x7ffff8aec010) at bytecode.c:519
Could you get that code file under gdb again, do
(gdb) source /path/to/source/of/xemacs/src/.gdbinit
(gdb) ldp (Lisp_Object) 39408616
(gdb) ldp * (Lisp_Object *) 0x7ffff8aec010
and post the results here, please?
Thanks for reporting this, and (in advance) for any help you can give
with the above questions!
Steve
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta