1 Return-Path: <m.walters@qmul.ac.uk>
\r
2 X-Original-To: notmuch@notmuchmail.org
\r
3 Delivered-To: notmuch@notmuchmail.org
\r
4 Received: from localhost (localhost [127.0.0.1])
\r
5 by olra.theworths.org (Postfix) with ESMTP id 20FB6431FB6
\r
6 for <notmuch@notmuchmail.org>; Sun, 9 Jun 2013 02:17:10 -0700 (PDT)
\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org
\r
11 X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5
\r
12 tests=[DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001,
\r
13 NML_ADSP_CUSTOM_MED=1.2, RCVD_IN_DNSWL_MED=-2.3] autolearn=disabled
\r
14 Received: from olra.theworths.org ([127.0.0.1])
\r
15 by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)
\r
16 with ESMTP id ZUdGqhk3Nej2 for <notmuch@notmuchmail.org>;
\r
17 Sun, 9 Jun 2013 02:17:02 -0700 (PDT)
\r
18 Received: from mail2.qmul.ac.uk (mail2.qmul.ac.uk [138.37.6.6])
\r
19 (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
\r
20 (No client certificate requested)
\r
21 by olra.theworths.org (Postfix) with ESMTPS id 237F3431FAE
\r
22 for <notmuch@notmuchmail.org>; Sun, 9 Jun 2013 02:17:02 -0700 (PDT)
\r
23 Received: from smtp.qmul.ac.uk ([138.37.6.40])
\r
24 by mail2.qmul.ac.uk with esmtp (Exim 4.71)
\r
25 (envelope-from <m.walters@qmul.ac.uk>)
\r
26 id 1Ulbk5-0000CK-MZ; Sun, 09 Jun 2013 10:16:56 +0100
\r
27 Received: from 93-97-24-31.zone5.bethere.co.uk ([93.97.24.31] helo=localhost)
\r
28 by smtp.qmul.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71)
\r
29 (envelope-from <m.walters@qmul.ac.uk>)
\r
30 id 1Ulbk5-0004pT-BY; Sun, 09 Jun 2013 10:16:53 +0100
\r
31 From: Mark Walters <markwalters1009@gmail.com>
\r
32 To: Austin Clements <amdragon@MIT.EDU>, notmuch@notmuchmail.org
\r
33 Subject: Re: [PATCH 2/2] emacs: Fix "no such file or directory" error
\r
34 In-Reply-To: <1370753138-15021-3-git-send-email-amdragon@mit.edu>
\r
35 References: <1370753138-15021-1-git-send-email-amdragon@mit.edu>
\r
36 <1370753138-15021-3-git-send-email-amdragon@mit.edu>
\r
37 User-Agent: Notmuch/0.15.2+171~ge2f30a2 (http://notmuchmail.org) Emacs/23.4.1
\r
38 (x86_64-pc-linux-gnu)
\r
39 Date: Sun, 09 Jun 2013 10:16:52 +0100
\r
40 Message-ID: <87hah7od8b.fsf@qmul.ac.uk>
\r
42 Content-Type: text/plain; charset=us-ascii
\r
43 X-Sender-Host-Address: 93.97.24.31
\r
44 X-QM-SPAM-Info: Sender has good ham record. :)
\r
45 X-QM-Body-MD5: 85f4dfb7015e393840e7ecdfba650ed0 (of first 20000 bytes)
\r
46 X-SpamAssassin-Score: -0.0
\r
47 X-SpamAssassin-SpamBar: /
\r
48 X-SpamAssassin-Report: The QM spam filters have analysed this message to
\r
50 spam. We require at least 5.0 points to mark a message as spam.
\r
51 This message scored -0.0 points.
\r
52 Summary of the scoring:
\r
53 * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
\r
54 provider * (markwalters1009[at]gmail.com)
\r
55 * -0.0 AWL AWL: From: address is in the auto white-list
\r
56 X-QM-Scan-Virus: ClamAV says the message is clean
\r
57 X-BeenThere: notmuch@notmuchmail.org
\r
58 X-Mailman-Version: 2.1.13
\r
60 List-Id: "Use and development of the notmuch mail system."
\r
61 <notmuch.notmuchmail.org>
\r
62 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
\r
63 <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
\r
64 List-Archive: <http://notmuchmail.org/pipermail/notmuch>
\r
65 List-Post: <mailto:notmuch@notmuchmail.org>
\r
66 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
\r
67 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
\r
68 <mailto:notmuch-request@notmuchmail.org?subject=subscribe>
\r
69 X-List-Received-Date: Sun, 09 Jun 2013 09:17:10 -0000
\r
72 Both of these patches look good to me +1. I was able to reproduce both
\r
73 bugs pretty reliably (the first one always unless masked by the second
\r
74 one which occurred about half the time). With these patches I cannot
\r
75 trigger either. Also all tests pass.
\r
77 My only tiny concern is I couldn't find any documentation on whether the
\r
78 return value of the filter-function matters at all. Austin's original
\r
79 fix (via irc) returned t and this returns nil in the failing case (i.e.,
\r
80 when results-buf is dead).
\r
88 On Sun, 09 Jun 2013, Austin Clements <amdragon@MIT.EDU> wrote:
\r
89 > Occasionally, when the user killed the search buffer when the CLI
\r
90 > process was still running, Emacs would run the
\r
91 > notmuch-start-notmuch-sentinel sentinel twice. The first call would
\r
92 > process and delete the error output file and the second would fail
\r
93 > with an "Opening input file: no such file or directory, ..." error
\r
94 > when attempting to access the error file.
\r
96 > Emacs isn't supposed to run the sentinel twice. The reason it does is
\r
97 > rather subtle (and probably a bug in Emacs):
\r
99 > 1) When the user kills the search buffer, Emacs invokes
\r
100 > kill_buffer_processes, which sends a SIGHUP to notmuch, but doesn't do
\r
101 > anything else. Meanwhile, suppose the notmuch search process has
\r
102 > printed some more output, but Emacs hasn't consumed it yet (this is
\r
103 > critical and is why this error only happens sometimes).
\r
105 > 2) Emacs gets a SIGCHLD from the dying notmuch process, which invokes
\r
106 > handle_child_signal, which sets the new process status, but can't do
\r
107 > anything else because it's a signal handler.
\r
109 > 3) Emacs returns to its idle loop, which calls status_notify, which
\r
110 > sees that the notmuch process has a new status. This is where things
\r
113 > 3.1) Emacs guarantees that it will run process filters on any
\r
114 > unconsumed output before running the process sentinel, so
\r
115 > status_notify calls read_process_output, which consumes the final
\r
116 > output and calls notmuch-search-process-filter.
\r
118 > 3.1.1) notmuch-search-process-filter checks if the search buffer is
\r
119 > still alive and, since it's not, it calls delete-process.
\r
121 > 3.1.1.1) delete-process correctly sees that the process is already
\r
122 > dead and doesn't try to send another signal, *but* it still modifies
\r
123 > the status to "killed". To deal with the new status, it calls
\r
124 > status_notify. Dun dun dun. We've seen this function before.
\r
126 > 3.1.1.1.1) The *recursive* status_notify invocation sees that the
\r
127 > process has a new status and doesn't have any more output to consume,
\r
128 > so it invokes our sentinel and returns.
\r
130 > 3.2) The outer status_notify call (which we're still in) is now done
\r
131 > flushing pending process output, so it *also* invokes our sentinel.
\r
133 > This patch addresses this problem at step 3.1.1, where the filter
\r
134 > calls delete-process, since this is a strange and redundant thing to
\r
137 > emacs/notmuch.el | 3 +--
\r
138 > 1 file changed, 1 insertion(+), 2 deletions(-)
\r
140 > diff --git a/emacs/notmuch.el b/emacs/notmuch.el
\r
141 > index 7994d74..a9949a1 100644
\r
142 > --- a/emacs/notmuch.el
\r
143 > +++ b/emacs/notmuch.el
\r
144 > @@ -821,8 +821,7 @@ non-authors is found, assume that all of the authors match."
\r
145 > (parse-buf (process-get proc 'parse-buf))
\r
146 > (inhibit-read-only t)
\r
148 > - (if (not (buffer-live-p results-buf))
\r
149 > - (delete-process proc)
\r
150 > + (when (buffer-live-p results-buf)
\r
151 > (with-current-buffer parse-buf
\r
152 > ;; Insert new data
\r
157 > _______________________________________________
\r
158 > notmuch mailing list
\r
159 > notmuch@notmuchmail.org
\r
160 > http://notmuchmail.org/mailman/listinfo/notmuch
\r