Re: [Bug: 21.4.22] Sporadic crash entering a group with Gnus
>>>> On Tue, 17 Feb 2009 22:51:40 +0900, "Stephen J.
Turnbull" <stephen(a)xemacs.org> said:
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).
The shadows are all the same. I install XEmacs and the packages to
AFS so it's easily available to all the workstations. For my laptop,
though, I need an offline solution and so I use unison to keep
.xemacs/packages in sync with AFS space. And because I like to have a
single init.el, both are in the load-path.
>
----------------------------------------------------------------------
> 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.
I'm pretty confident that nothing in my load path has ever been
compiled by GNU Emacs.
> # 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.
I'll try that, thanks.
Do you have any customizations of `gnus-summary-highlight'?
No. I've not touched it.
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?
Sure, though I don't know the mechanics of doing so.
> #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?
Unfortunately when I do this the results are probably not what you wanted.
(gdb) source /home/dsg/xemacs-21.4.22/src/.gdbinit
Really redefine built-in command "ptype"? (y or n) [answered Y; input not from
terminal]
(gdb) ldp (Lisp_Object) 39408616
You can't do that without a process to debug.
(gdb) ldp * (Lisp_Object *) 0x7ffff8aec010
You can't do that without a process to debug.
Thanks for reporting this, and (in advance) for any help you can
give
with the above questions!
I am happy to help track this down however I can.
Thanks,
--
Dave Goldberg
Associate Department Head, G06A: Advanced Technical Computing Center
The MITRE Corporation \ MS K331 \ 202 Burlington Rd. \ Bedford, MA 01730
dsg(a)mitre.org \ 781-271-3887 (W) \ 781-439-7875 (M)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta