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

From: Michael Albinus <[email-masked]>
Date: Sat, 18 May 2024 20:22:21 +0200

Eli Zaretskii <[email-masked]> writes:

Hi Eli,

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

I agree, the Lispy D-Bus event should be generated only in dbusbind.c.

I've checked Emacs proper (lisp/ subdirectory), GNU ELPA and NonGNU ELPA
for the string "dbus-event". Obviously, it is contained in dbus.el. In
helm-core.el and tramp-gvfs.el, `dbus-event' is added to
`while-no-input-ignore-events'. In notifications.el, secrets.el,
tramp-gvfs.el and zeroconf.el accessor funtions of the `dbus-event'
structure are used. None of this looks strange to me.

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

Yes.

Best regards, Michael.