[Bug: 21.4.19] Crashed in Gnus

[Eric D. Hendrickson]

"Stephen J. Turnbull" <stephen at xemacs.org> writes:

> Sorry for the delay; our mailing list host moved physically, and the
> ISP snafued the firewall at the new location.

No worries, thanks for your reply.

>     Eric> I *think* I hit 'r' to reply to a mail message, while
>
> Looks that way from the Lisp backtrace.

Yah I thought so too but I really can't remember what key I hit when
it happened, I was so surprised.

>     Eric> looking at my Summary buffer.  And BOOM it crashed.
>     Eric> Appended at the end is a C stack trace from gdb and a Lisp
>     Eric> backtrace from the crash.
>
> I'm sorry, but neither backtrace is much help.  The Lisp backtrace is
> too high-level (Lisp never crashes, only C does :-), and the C
> backtrace doesn't have any symbols or arguments in it, so it's hard to
> guess what's going on.

Yes I noticed that...  the binary is stripped.  :(

> First question:  has this happened before or since?  Can you reproduce
> it?

No and I don't know how but if it happens again I will let you know.

> Second: where did you get the Gnus in site-packages?  It is shadowing
> the Gnus from our distribution; this is unclean but probably not the
> cause (you should be able to safely remove Gnus using M-x
> list-packages).  It doesn't seem to be an XEmacs package, since it
> doesn't appear in the list of installed packages in your report.

I hadn't noticed that I am still running a Gnus from site-packages -
I'll make sure that the next time I start XEmacs (I'll try to do it
soon) I move that older version of Gnus out of site-packages and try
to get by with the stock (newer) version.  Not sure why I put a copy
in site-packages now...

I used to do a lot of beta testing for Gnus and I assume when I put
that out there it was a newer version than the stock version.

I don't have as much time for tinkering with Gnus as I used to so I
should probably just use the stock version anyway.

Hopefully that will work around this problem.

FYI - I also used to do a lot of beta testing and bug fixing for
Emacs, gdb and gcc back in the early 90's.

> Since the crash occurs in the bytecode-interpreter:
>
>     #7  0x080ad182 in assert_failed ()
>     #8  0x08090519 in execute_rare_opcode ()
>     #9  0x0808f7b2 in funcall_compiled_function ()
>
> either you have stack corruption, or your Gnus contains an illegal
> bytecode.  ISTR that XEmacs 21.5-compiled code is not compatible with
> XEmacs 21.4; perhaps if you remove all the .elc files and re-byte-
> compile the crash can be prevented.  Also, GNU-Emacs-compiled bytecode
> is definitely incompatible with XEmacs.

However it shouldn't cause XEmacs to crash, yes?

>     Eric> Let me know if there is any more help I can provide!
>
> If (1) you have the core file and (2) Fedora provides a debug package
> which has the symbol table in it, you could get the package, install
> the symbol table, run gdb on the core file, and get a better
> backtrace.
>
> If not, you would have to get the sources or the debug package, if
> source compile with debugging, run under gdb (this doesn't slow XEmacs
> down, but does use system resources) and hope (?!) the crash happens
> again.

I doubt if there is a debug package but I will check.  I might be able
to produce one by modifying the source rpm though.

Cheers,
Eric