Subject: bug#12814: 24.3.50; Emacs crash in event_to_kboard at keyboard.c:3421

From: Tassilo Horn <[email-masked]>
Date: Thu, 08 Nov 2012 08:56:05 +0100

Eli Zaretskii <[email-masked]> writes:

>> the next crash occured.  This time not while typing but while
>> scrolling (<down>) in an info buffer.
>
> If you were scrolling down, how come Emacs was processing a selection
> request event?

I have no clue.  The crash just happened again while typing in a mail,
and it also was a SELECTION_REQUEST_EVENT with inaccessible
frame_or_window.

> AFAIK, that means some other application requested the selection data
> owned by Emacs.

Hm, I'm running a GNOME3 desktop.  Right now, there are only some
terminals running and a browser.  Ah, and the parcellite clipboard
manager.  But those haven't been updated lately, and a week ago, emacs
didn't crash.

> Someone who knows their way around X selection code should help you
> find out where does this value of frame_or_window come from, and how
> that Lisp object became inaccessible.

Looking at the ChangeLog, this one looks suspicious to me:

2012-11-02  Dmitry Antipov  <[email-masked]>

	Remove pad from struct input_event.
	* termhooks.h (struct input_event): Remove padding field.
	Adjust comment.
	* keyboard.c (event_to_kboard): Simplify because frame_or_window
	member is never cons for a long time.  Adjust comment.
	(mark_kboards): Adjust because SELECTION_REQUEST_EVENT and
	SELECTION_CLEAR_EVENT has no Lisp_Objects to mark.  Add comment.
	* xterm.c (handle_one_xevent): Do not initialize frame_or_window
	field of SELECTION_REQUEST_EVENT and SELECTION_CLEAR_EVENT.

It would fit the time frame since when the crashes appeared first.

Bye,
Tassilo