GNU bug report logs - #70760
29.3.50; core dumps when copy in other apps

Previous Next

Full log

View this message in rfc822 format

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: kun.liu <at> gmail.com, 70760 <at> debbugs.gnu.org
Subject: bug#70760: 29.3.50; core dumps when copy in other apps
Date: Sat, 18 May 2024 20:22:21 +0200

Eli Zaretskii <eliz <at> gnu.org> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.