bug#21313: 25.0.50; Strange errors from dbus-handle-event

[Eli Zaretskii <eliz@gnu.org>]

> From: Tassilo Horn <tsdh@gnu.org>
> Cc: 21313@debbugs.gnu.org
> Date: Fri, 11 Sep 2015 15:06:48 +0200
> 
> > So I suggest to read the description of the root cause posted by
> > Robert Pluim in http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21337#31,
> > and then look for something very similar, but involving other sources
> > of input events, perhaps D-Bus.  The symptoms you describe exactly
> > match what he explained there.
> 
> The problem is that I have almost no idea what that code does and how it
> is intended to work, so I can't really debug it in a sensible way.

You mean, wait_reading_process_output?  Please feel free to ask
questions about the things you don't understand.

In a nutshell, it waits until one of the input sources has some input,
and then we read from that source using whatever method is appropriate
for interpreting that source.

> If you have some ideas where things could go wrong, I'm happy to do
> whatever may help.

I think things go wrong exactly like in that other bug: we have some
source ready to be read from, but dispatch those events to a "handler"
for another source.

> Maybe adding some debugging code or conditional breakpoints could
> narrow down the scope a bit?

I'd start by looking at the indicators returned by 'pselect'.

> BTW, the last errors came from `file-notify-handle-event' but I'm
> reasonably sure that in this emacs session I only had used Gnus so far.
> I don't use auto-revert-mode, so actually filenotify.el should not even
> have been loaded so far and no watches should have existed.  My current
> emacs session is the same: only Gnus => (featurep 'filenotify) ;=> nil.
> Does that give any clue?

My theory is that we think there's an inotify event waiting to be
read, where in fact the event is of another kind, perhaps from D-Bus.
The flags returned by 'pselect' should tell you.