From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tassilo Horn Newsgroups: gmane.emacs.bugs Subject: bug#21313: 25.0.50; Strange errors from dbus-handle-event Date: Tue, 15 Sep 2015 17:37:02 +0200 Message-ID: <87r3lziti9.fsf@gnu.org> References: <877foo4nkd.fsf@gnu.org> <87wpvzs4r3.fsf@gnu.org> <87bnd9cf7g.fsf@gnu.org> <831te53zbq.fsf@gnu.org> <871te5cdg7.fsf@gnu.org> <83wpvx2h16.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1442331505 2988 80.91.229.3 (15 Sep 2015 15:38:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 15 Sep 2015 15:38:25 +0000 (UTC) Cc: 21313@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Sep 15 17:38:15 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZbsJ9-0007Hi-Kc for geb-bug-gnu-emacs@m.gmane.org; Tue, 15 Sep 2015 17:38:11 +0200 Original-Received: from localhost ([::1]:43884 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbsJ8-0003Kd-Kr for geb-bug-gnu-emacs@m.gmane.org; Tue, 15 Sep 2015 11:38:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47015) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbsJ3-0003Hv-Vj for bug-gnu-emacs@gnu.org; Tue, 15 Sep 2015 11:38:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZbsJ0-00064i-Pu for bug-gnu-emacs@gnu.org; Tue, 15 Sep 2015 11:38:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:41237) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbsJ0-00064J-NJ for bug-gnu-emacs@gnu.org; Tue, 15 Sep 2015 11:38:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZbsJ0-0002AL-CY for bug-gnu-emacs@gnu.org; Tue, 15 Sep 2015 11:38:02 -0400 X-Loop: help-debbugs@gnu.org In-Reply-To: <877foo4nkd.fsf@gnu.org> Resent-From: Tassilo Horn Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 15 Sep 2015 15:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21313 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21313-submit@debbugs.gnu.org id=B21313.14423314268209 (code B ref 21313); Tue, 15 Sep 2015 15:38:02 +0000 Original-Received: (at 21313) by debbugs.gnu.org; 15 Sep 2015 15:37:06 +0000 Original-Received: from localhost ([127.0.0.1]:33447 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZbsI5-00028K-I9 for submit@debbugs.gnu.org; Tue, 15 Sep 2015 11:37:05 -0400 Original-Received: from deliver.uni-koblenz.de ([141.26.64.15]:50591) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZbsI3-000287-3T for 21313@debbugs.gnu.org; Tue, 15 Sep 2015 11:37:04 -0400 Original-Received: from thinkpad-t440p (dhcp23.uni-koblenz.de [141.26.71.23]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by deliver.uni-koblenz.de (Postfix) with ESMTPSA id E25A71A82D6; Tue, 15 Sep 2015 17:37:02 +0200 (CEST) User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:106596 Archived-At: Eli Zaretskii 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