[ 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