bug#70760: 29.3.50; core dumps when copy in other apps

[Michael Albinus via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Kun Liu <kun.liu@gmail.com> writes:

Hi,

> I spent more time on this issue. I watched closely both "dbus-monitor -
> -system" and "dbus-monitor" outputs, while trying to replicate the
> issue in Emacs. It appears that just as you said, when Emacs reported
> invalid dbus events, which crashes Emacs sometimes, dbus-monitor
> outputs never showed any messages immediately preceding or following
> the error.

This is another evidence why I believe the invalid D-Bus event hasn't
been injected to Emacs from external. It is something which happens in
Emacs internally, and that's why I believe we cannot simply ignore
bad-formed D-Bus events.

> Which really begs the question, if dbus did not have any messages for
> Emacs at the time, why did Emacs think there was a message for it?

Well, look at the architecture.

Emacs id connected to both the system and session D-Bus via a file
descriptor. From time to time Emacs receives events via this way in
xd_read_message_1. This will be transformed into a "Lispy event", a list
which starts with the symbol `dbus-event'. Something like

--8<---------------cut here---------------start------------->8---
(dbus-event :system 2 2 org.freedesktop.DBus :1.492 nil nil
 nil dbus-call-method-handler)
--8<---------------cut here---------------end--------------->8---

This "Lispy event" will be stored in Emacs' input event queue, see line
1759 or 1803 in dbusbind.c. There's no further action in dbusbind.c wrt
to this event afterwards,

The Emacs main loop checks periodically the input event queue. If it
detects something, it takes action. Often it is just a keyboard
event. But there are also special events like the D-Bus event. For them,
the variable `special-event-map', checking first for the event type, and
call the respective handler then. For D-Bus events, this would be the
call (dbus-handle-event event), which we have seen in your backtraces.

But what if an event is added to the input event queue, which has an
arbitrary format? Or an existing event has been modified? It could look
like a D-Bus event (the car of the event is `dbus-event'), but the rest
of the list is random. It must not come via the dbusevent.c mechanism
I've explained above, anybody can push such an event onto then input
event queue. But I have no idea how to debug this.

Best regards, Michael.