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

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: kun.liu@gmail.com,  70760@debbugs.gnu.org
> Date: Sat, 18 May 2024 18:55:51 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > OK.  So how could a non-D-Bus event end up being interpreted as a
> > D-Bus event?
> 
> We see calls of dbus-event-handler in the backtrace shown by Kun
> Liu. This can happen only via special-mode-map, when an event is
> detected in the event queue, which is a list with the car being the
> symbol `dbus-event'. The rest of the event is not checked at this point,
> the event is checked for D-Bus properness in the handler.
> 
> We have also seen by the tests of Kun Liu, that no external D-Bus event
> has arrived at this time. So I guess either such an invalid D-Bus event
> has been pushed by another package to the event queue, or an existing
> valid event has been modified that the car is the symbol `dbus-event'.

But the only place in Emacs that generates dbus-event events is
dbusbind.c, right?  So in that case, the first suspect is some Lisp
package that pushes such events onto the Emacs event queue, do you
agree?

> > The only hint we have until now is that this happens when copying
> > stuff from other applications.  Does that ring any bells or suggest
> > any ideas?
> 
> Not for me. What I have seen is that xd_add_watch calls add_read_fd. But
> in process.c, there is also the function add_non_keyboard_read_fd. I
> have no idea what's the difference, but this function must exist for a
> reason. Would it make sense to use this function instead? Just a wild
> guess.

Yes, the descriptors we use to read sub-process output are
non-keyboard descriptors.  But as far as I understand what you say,
there's no way for those descriptors to generate dbus-event events.