From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Robert Pluim Newsgroups: gmane.emacs.bugs Subject: bug#21337: 25.0.50; inotify error message Date: Wed, 26 Aug 2015 19:02:23 +0200 Message-ID: <87twrm2db4.fsf@gmail.com> References: <87k2skyjf2.fsf@gmail.com> <83d1ychefg.fsf@gnu.org> <87oahw8xmv.fsf@gmail.com> <83a8tghcgr.fsf@gnu.org> <87twrobpet.fsf@gmail.com> <836144hagi.fsf@gnu.org> <87io84pmec.fsf@gmail.com> <83si78fpi5.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1440608617 22070 80.91.229.3 (26 Aug 2015 17:03:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 26 Aug 2015 17:03:37 +0000 (UTC) Cc: 21337@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Aug 26 19:03:28 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 1ZUe6c-00084S-72 for geb-bug-gnu-emacs@m.gmane.org; Wed, 26 Aug 2015 19:03:22 +0200 Original-Received: from localhost ([::1]:39448 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUe6a-0004CK-Qd for geb-bug-gnu-emacs@m.gmane.org; Wed, 26 Aug 2015 13:03:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59247) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUe6N-00048M-56 for bug-gnu-emacs@gnu.org; Wed, 26 Aug 2015 13:03:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZUe6I-00022v-Im for bug-gnu-emacs@gnu.org; Wed, 26 Aug 2015 13:03:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:46836) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUe6I-00022o-FI for bug-gnu-emacs@gnu.org; Wed, 26 Aug 2015 13:03:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZUe6H-0002d8-NM for bug-gnu-emacs@gnu.org; Wed, 26 Aug 2015 13:03:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Robert Pluim Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 26 Aug 2015 17:03:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21337 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21337-submit@debbugs.gnu.org id=B21337.144060855210058 (code B ref 21337); Wed, 26 Aug 2015 17:03:01 +0000 Original-Received: (at 21337) by debbugs.gnu.org; 26 Aug 2015 17:02:32 +0000 Original-Received: from localhost ([127.0.0.1]:39042 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUe5m-0002c8-Ip for submit@debbugs.gnu.org; Wed, 26 Aug 2015 13:02:31 -0400 Original-Received: from mail-wi0-f181.google.com ([209.85.212.181]:37513) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUe5j-0002bz-LE for 21337@debbugs.gnu.org; Wed, 26 Aug 2015 13:02:28 -0400 Original-Received: by widdq5 with SMTP id dq5so21288950wid.0 for <21337@debbugs.gnu.org>; Wed, 26 Aug 2015 10:02:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:in-reply-to:references:user-agent :gmane-reply-to-list:date:message-id:mime-version:content-type; bh=KihI+m/7ne1IbuQFWDYbbSLvq43PQX9uv2ECpKv1Ew4=; b=eiSEXxZOIaomjFZ5OmRuXU4AY73glqW7mdV7Uv9jf10sN7htjxi59rTkPpD2Mh9IGD Cj5z3srQoaNiEFkR2NkVH5rOLMA8LSkrcqDWDULJYIIpShvKbXDngYK+ctGxN0iFhdPn EIQddGv3r6pH3vkvotAbcqaUXa9Lf3HZjO9VcUM5IoTBOPeAebwTl/+blfg4yG1yHkUB nyalewf7riLVMKG5kQ+iXKdXyNqD8bPbVXFC6FlWMSZgj6J4BS8k96p7ENCuzWRk/FIU l5+8wHOZdC+nXmdfK8vzhbXPb1rVCEQ4HXrLu4XwCIUizssnbU2sOQuY1VhoLb6FfP7a 2yJQ== X-Received: by 10.194.78.84 with SMTP id z20mr61899624wjw.141.1440608546960; Wed, 26 Aug 2015 10:02:26 -0700 (PDT) Original-Received: from rpluim-ubuntu ([2a01:e34:ecfc:a090:6941:8a0f:ba9f:11db]) by smtp.gmail.com with ESMTPSA id e8sm8506309wiz.0.2015.08.26.10.02.25 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 26 Aug 2015 10:02:25 -0700 (PDT) In-Reply-To: <83si78fpi5.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 24 Aug 2015 22:36:02 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) Gmane-Reply-To-List: yes 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:105846 Archived-At: Eli Zaretskii writes: >> is that the read will succeed, however to_read is very often 0, so >> it's not surprising the read fails. > > That's strange, isn't it? If to_read is zero, how come pselect > indicated that FD has stuff to be read? pselect didn't, but we fooled ourselves into thinking it did. I suspected this was down to Gnus tickling some file descriptor handling bug, and since the only code I could see in wait_reading_process_output() that looked like it might be messing things up was under a HAVE_GNUTLS define, I rebuilt without GnuTLS, and the problem went away. After debugging some more, here's my current theory (look around line 4904 of process.c: 1. the file descriptor for inotify events is checked by xg_select (since HAVE_GLIB == 1) using the Available fd_set 2. there is nothing to be read, so xg_select returns nfds = 0. However, the inotify FD is still set in Available, which is unexpected but not wrong. 3. We then run: for (channel = 0; channel < FD_SETSIZE; ++channel) if (! NILP (chan_process[channel])) { struct Lisp_Process *p = XPROCESS (chan_process[channel]); if (p && p->gnutls_p && p->gnutls_state && ((emacs_gnutls_record_check_pending (p->gnutls_state)) > 0)) { nfds++; eassert (p->infd == channel); FD_SET (p->infd, &Available); } } which checks if any of the TLS file descriptors have waiting data that hasn't been indicated by xg_select, and sets the corresponding bit in the Available fd_set. In my case one of them does, so we increment nfds 4. We then reach if (no_avail || nfds == 0) continue; 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); } around line 5085 and loop over all the FDs we know about, checking to see if any of them are set in the Available fd_set 5. the inotify FD is still set in Available, so we call its callback function, which tries to read data when it shouldn't Step 5 should never happen, but because step 2 did not clear the Available fd_set, and the HAVE_GNUTLS code incremented nfds, we think there's data to be read. The following patch, which zeros out Available when the GNUTLS code does its thing has fixed things for me. I've convinced myself it has no bad side-effects, but would appreciate a second opinion, especially since the option also exists to just zero out Available unconditionally when nfds==0. diff --git a/src/process.c b/src/process.c index 9d8fa22..dcc004e 100644 --- a/src/process.c +++ b/src/process.c @@ -4913,6 +4913,10 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd, data is available in the buffers manually. */ if (nfds == 0) { + fd_set tls_available; + int set = 0; + + FD_ZERO (&tls_available); if (! wait_proc) { /* We're not waiting on a specific process, so loop @@ -4933,7 +4937,8 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd, { nfds++; eassert (p->infd == channel); - FD_SET (p->infd, &Available); + FD_SET (p->infd, &tls_available); + set++; } } } @@ -4950,9 +4955,12 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd, nfds = 1; eassert (0 <= wait_proc->infd); /* Set to Available. */ - FD_SET (wait_proc->infd, &Available); + FD_SET (wait_proc->infd, &tls_available); + set++; } } + if (set) + Available = tls_available; } #endif }