[Bug: 21.4.22] Sporadic crash entering a group with Gnus

[David S. Goldberg]

>>>>> On Tue, 17 Feb 2009 22:51:40 +0900, "Stephen J. Turnbull" <stephen at 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 at mitre.org \ 781-271-3887 (W) \ 781-439-7875 (M)