[ sending this note back to the list, per private requests ]
Kyle (and others), it didn't take long...
XEmacs was started thus:
xemacs -geometry 207x89+1282+0 -f gnus-init
where "gnus-init" is just a small wrapper around Gnus' start-up for me:
(defun gnus-init ()
"Start Gnus and smallify."
(interactive)
(gnus-no-server)
(x-active-icon-toggle nil))
The exact keyboard sequence that had occurred when the SEGV was taken
was that I was reading comp.emacs.xemacs (hm! :-), and I exited with a
common set of keystrokes for me:
q l < s g
In Gnus, that means
- quit the group
- reduce the listed group set to only those with unread articles
- goto the top of the *Group* buffer
- save .newsrc*
- get new news
This is a very common key sequence for me; I do it a lot when I notice
mail arriving via xbiff and want to go get it. I type that sequence a
lot, and quickly.
Significantly, there was
- no mouse activity
- no window manager activity
Just keystrokes, maneuvering with bland Gnus command bindings.
Gnus didn't even get as far as carrying out the `l' list-reduction
command. It cleaned out the *Summary* buffer, leaving only *Group*
showing, still cluttered with zero-message groups showing, and then
stopped in gdb on SEGV.
The stack trace is the same: SEGV thrown on
259 assert (EQ (FRAME_TYPE (f), sym));
I'm a little confused by the stack, considering that this is an inline
func in frame.h; the next stack frame shows x_event_to_emacs_event()
at a line where it's calling x_to_emacs_keysym()...there must be some
macro call which gets to error_check_frame_type() somehow, but I don't
see it right this instant.
I'm leaving this (dying) XEmacs attached to the gdb which caught it,
so I am open to suggestions for things to look at. Anything you'd
like to see pobj'd...?
--karl