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

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

> 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'.

> Can we arrange for some breakpoints or watchpoints to
> try to catch these inputs on their way to being interpreted as D-Bus
> events, so that we could try figuring out where did those inputs come
> from?

No idea. The backtrace shown by Kun Liu starts with the call of
dbus-event-handler. I have no idea how to watch the event queue - this
is out of my knowledge.

> 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.

Best regards, Michael.