GNU bug report logs - #21313
25.0.50; Strange errors from dbus-handle-event

Previous Next

Full log

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

From: Tassilo Horn <tsdh <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 21313 <at> debbugs.gnu.org
Subject: Re: bug#21313: 25.0.50; Strange errors from dbus-handle-event
Date: Tue, 15 Sep 2015 17:37:02 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

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

As far as I understand, the file descriptors with pending input are
collected in the fd_set Available, and then this loop gives, e.g., dbus
and inotify handlers a chance to read input from the file descriptors
and convert it to events.

      for (channel = 0; channel <= max_input_desc; ++channel)
        {
          struct fd_callback_data *d = &fd_callback_info[channel];
          if (d->func
              && ((d->condition & FOR_READ
                   && FD_ISSET (channel, &Available))
                  || (d->condition & FOR_WRITE
                      && FD_ISSET (channel, &write_mask))))
            d->func (channel, d->data);
        }

I wondered why channel is not removed from Available here.  I mean,
input was available, and then the handlers registered using add_read_fd
by inotify or dbus consumed the input, so there's probably no input
left.  So I tried this patch

--8<---------------cut here---------------start------------->8---
diff --git a/src/process.c b/src/process.c
index ed5f4c0..7985e37 100644
--- a/src/process.c
+++ b/src/process.c
@@ -5036,7 +5036,10 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd,
 		   && FD_ISSET (channel, &Available))
 		  || (d->condition & FOR_WRITE
 		      && FD_ISSET (channel, &write_mask))))
-            d->func (channel, d->data);
+	    {
+	      d->func (channel, d->data);
+	      FD_CLR (channel, &Available);
+	    }
 	}
 
       for (channel = 0; channel <= max_process_desc; channel++)
--8<---------------cut here---------------end--------------->8---

and since then the problem has not appeared again and I can't see any
obvious other malfunction.  But of course that's really a naive change.
I can grasp the big picture of wait_reading_process_output but not all
the details.

Bye,
Tassilo

Previous Next

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