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

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> 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  <dmantipov@yandex.ru>

        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