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

Previous Next

Full log

Message #83 received at 70760 <at> debbugs.gnu.org (full text, mbox):

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

> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: kun.liu <at> gmail.com,  70760 <at> debbugs.gnu.org
> Date: Sat, 18 May 2024 12:32:29 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> Hi Eli,
> 
> >> 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.
> >
> > Which file descriptors do we listen to, apart of sub-processes and
> > inotify?
> 
> See xd_add_watch. xd_find_watch_fd returns the file descriptor
> reponsible for a given D-Bus connection (this is a bus like the system
> bus, the session bus, or a private bus). This file descriptor is added
> to Emacs via add_write_fd and add_read_fd, using the callback
> xd_read_queued_messages. So it might look like a subprocess ...

You are saying that output of some subprocess could be interpreted as
D-Bus event?  How do we know which inputs to try to interpret as D-Bus
events?  IOW, can you hypothesize how could we take some non-D-Bus
input and end up interpreting it as D-Bus?

Previous Next

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