From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 0BEFC431FC3 for ; Sat, 8 Jun 2013 21:46:13 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6IXH3G8+abBO for ; Sat, 8 Jun 2013 21:46:07 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) by olra.theworths.org (Postfix) with ESMTP id B83A0431FB6 for ; Sat, 8 Jun 2013 21:46:01 -0700 (PDT) X-AuditID: 12074423-b7f546d0000040c3-59-51b408899ae5 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id F7.EE.16579.98804B15; Sun, 9 Jun 2013 00:46:01 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id r594joEU004331; Sun, 9 Jun 2013 00:45:50 -0400 Received: from drake.dyndns.org (216-15-114-40.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com [216.15.114.40]) (authenticated bits=0) (User authenticated as amdragon@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r594jmcS009514 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Sun, 9 Jun 2013 00:45:50 -0400 Received: from amthrax by drake.dyndns.org with local (Exim 4.77) (envelope-from ) id 1UlXVk-0003wW-Ie; Sun, 09 Jun 2013 00:45:48 -0400 From: Austin Clements To: notmuch@notmuchmail.org Subject: [PATCH 2/2] emacs: Fix "no such file or directory" error Date: Sun, 9 Jun 2013 00:45:38 -0400 Message-Id: <1370753138-15021-3-git-send-email-amdragon@mit.edu> X-Mailer: git-send-email 1.7.10.4 In-Reply-To: <1370753138-15021-1-git-send-email-amdragon@mit.edu> References: <1370753138-15021-1-git-send-email-amdragon@mit.edu> X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMIsWRmVeSWpSXmKPExsUixCmqrdvJsSXQ4NVGcYs9+7wsrt+cyezA 5HH3NJfHs1W3mAOYorhsUlJzMstSi/TtErgy3nRNZCpYJFaxcfo8pgbGyUJdjJwcEgImEl2L GtkhbDGJC/fWs3UxcnEICexjlPi3ZzsrSEJIYAOjxM/nWhD2bSaJk3esIIrmMkrMPPcTrJtN QENi2/7ljCC2iIC0xM67s4GaOTiYBZwk2tq8QMLCAo4SC2edBAuzCKhK9HytAQnzCjhIXDv4 E+oGRYnuZxPYQGxOoPK270+YQcqFgGr6u9wnMPIvYGRYxSibklulm5uYmVOcmqxbnJyYl5da pGuml5tZopeaUrqJERQ+7C7KOxj/HFQ6xCjAwajEwyuwbnOgEGtiWXFl7iFGSQ4mJVHeFQxb AoX4kvJTKjMSizPii0pzUosPMUpwMCuJ8F46D1TOm5JYWZValA+TkuZgURLnvZZy019IID2x JDU7NbUgtQgmK8PBoSTB28gONFSwKDU9tSItM6cEIc3EwQkynAdo+GSQGt7igsTc4sx0iPwp Rl2Ozecnv2MUYsnLz0uVEuctAikSACnKKM2DmwOL+1eM4kBvCUOM4gGmDLhJr4CWMAEtmf5q A8iSkkSElFQD41ljaZOrjRy1xhc/f6jiv9Z9zWxaP+O9m+8nXHpl1tJydG+45SNH0cNXnqYU Hdrqu+9FWKjvsR/36r/EJMvLBp8IujpFKX/5gsAPqTKBO1vnBcved2aarvL54k+vRc7P8zZX K3yc8eLimm/+LRtFHwtppvAsf5BR9G7Jj+SFFySuHtmn4thbukqJpTgj0VCLuag4EQCjJdc+ 1gIAAA== X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jun 2013 04:46:13 -0000 Occasionally, when the user killed the search buffer when the CLI process was still running, Emacs would run the notmuch-start-notmuch-sentinel sentinel twice. The first call would process and delete the error output file and the second would fail with an "Opening input file: no such file or directory, ..." error when attempting to access the error file. Emacs isn't supposed to run the sentinel twice. The reason it does is rather subtle (and probably a bug in Emacs): 1) When the user kills the search buffer, Emacs invokes kill_buffer_processes, which sends a SIGHUP to notmuch, but doesn't do anything else. Meanwhile, suppose the notmuch search process has printed some more output, but Emacs hasn't consumed it yet (this is critical and is why this error only happens sometimes). 2) Emacs gets a SIGCHLD from the dying notmuch process, which invokes handle_child_signal, which sets the new process status, but can't do anything else because it's a signal handler. 3) Emacs returns to its idle loop, which calls status_notify, which sees that the notmuch process has a new status. This is where things get interesting. 3.1) Emacs guarantees that it will run process filters on any unconsumed output before running the process sentinel, so status_notify calls read_process_output, which consumes the final output and calls notmuch-search-process-filter. 3.1.1) notmuch-search-process-filter checks if the search buffer is still alive and, since it's not, it calls delete-process. 3.1.1.1) delete-process correctly sees that the process is already dead and doesn't try to send another signal, *but* it still modifies the status to "killed". To deal with the new status, it calls status_notify. Dun dun dun. We've seen this function before. 3.1.1.1.1) The *recursive* status_notify invocation sees that the process has a new status and doesn't have any more output to consume, so it invokes our sentinel and returns. 3.2) The outer status_notify call (which we're still in) is now done flushing pending process output, so it *also* invokes our sentinel. This patch addresses this problem at step 3.1.1, where the filter calls delete-process, since this is a strange and redundant thing to do anyway. --- emacs/notmuch.el | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/emacs/notmuch.el b/emacs/notmuch.el index 7994d74..a9949a1 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -821,8 +821,7 @@ non-authors is found, assume that all of the authors match." (parse-buf (process-get proc 'parse-buf)) (inhibit-read-only t) done) - (if (not (buffer-live-p results-buf)) - (delete-process proc) + (when (buffer-live-p results-buf) (with-current-buffer parse-buf ;; Insert new data (save-excursion -- 1.7.10.4