From 7abd9a529c4ae1788d43f45297f104d047ab2e7c Mon Sep 17 00:00:00 2001 From: Mark Walters Date: Sun, 9 Jun 2013 10:16:52 +0100 Subject: [PATCH] Re: [PATCH 2/2] emacs: Fix "no such file or directory" error --- eb/d76a6e96abc8843ce834b886e3f344e9139e07 | 160 ++++++++++++++++++++++ 1 file changed, 160 insertions(+) create mode 100644 eb/d76a6e96abc8843ce834b886e3f344e9139e07 diff --git a/eb/d76a6e96abc8843ce834b886e3f344e9139e07 b/eb/d76a6e96abc8843ce834b886e3f344e9139e07 new file mode 100644 index 000000000..3df8b51f3 --- /dev/null +++ b/eb/d76a6e96abc8843ce834b886e3f344e9139e07 @@ -0,0 +1,160 @@ +Return-Path: +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +Received: from localhost (localhost [127.0.0.1]) + by olra.theworths.org (Postfix) with ESMTP id 20FB6431FB6 + for ; Sun, 9 Jun 2013 02:17:10 -0700 (PDT) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: -1.098 +X-Spam-Level: +X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 + tests=[DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, + NML_ADSP_CUSTOM_MED=1.2, RCVD_IN_DNSWL_MED=-2.3] 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 ZUdGqhk3Nej2 for ; + Sun, 9 Jun 2013 02:17:02 -0700 (PDT) +Received: from mail2.qmul.ac.uk (mail2.qmul.ac.uk [138.37.6.6]) + (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) + (No client certificate requested) + by olra.theworths.org (Postfix) with ESMTPS id 237F3431FAE + for ; Sun, 9 Jun 2013 02:17:02 -0700 (PDT) +Received: from smtp.qmul.ac.uk ([138.37.6.40]) + by mail2.qmul.ac.uk with esmtp (Exim 4.71) + (envelope-from ) + id 1Ulbk5-0000CK-MZ; Sun, 09 Jun 2013 10:16:56 +0100 +Received: from 93-97-24-31.zone5.bethere.co.uk ([93.97.24.31] helo=localhost) + by smtp.qmul.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71) + (envelope-from ) + id 1Ulbk5-0004pT-BY; Sun, 09 Jun 2013 10:16:53 +0100 +From: Mark Walters +To: Austin Clements , notmuch@notmuchmail.org +Subject: Re: [PATCH 2/2] emacs: Fix "no such file or directory" error +In-Reply-To: <1370753138-15021-3-git-send-email-amdragon@mit.edu> +References: <1370753138-15021-1-git-send-email-amdragon@mit.edu> + <1370753138-15021-3-git-send-email-amdragon@mit.edu> +User-Agent: Notmuch/0.15.2+171~ge2f30a2 (http://notmuchmail.org) Emacs/23.4.1 + (x86_64-pc-linux-gnu) +Date: Sun, 09 Jun 2013 10:16:52 +0100 +Message-ID: <87hah7od8b.fsf@qmul.ac.uk> +MIME-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +X-Sender-Host-Address: 93.97.24.31 +X-QM-SPAM-Info: Sender has good ham record. :) +X-QM-Body-MD5: 85f4dfb7015e393840e7ecdfba650ed0 (of first 20000 bytes) +X-SpamAssassin-Score: -0.0 +X-SpamAssassin-SpamBar: / +X-SpamAssassin-Report: The QM spam filters have analysed this message to + determine if it is + spam. We require at least 5.0 points to mark a message as spam. + This message scored -0.0 points. + Summary of the scoring: + * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail + provider * (markwalters1009[at]gmail.com) + * -0.0 AWL AWL: From: address is in the auto white-list +X-QM-Scan-Virus: ClamAV says the message is clean +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 09:17:10 -0000 + + +Both of these patches look good to me +1. I was able to reproduce both +bugs pretty reliably (the first one always unless masked by the second +one which occurred about half the time). With these patches I cannot +trigger either. Also all tests pass. + +My only tiny concern is I couldn't find any documentation on whether the +return value of the filter-function matters at all. Austin's original +fix (via irc) returned t and this returns nil in the failing case (i.e., +when results-buf is dead). + +Best wishes + +Mark + + + +On Sun, 09 Jun 2013, Austin Clements wrote: +> 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 +> +> _______________________________________________ +> notmuch mailing list +> notmuch@notmuchmail.org +> http://notmuchmail.org/mailman/listinfo/notmuch -- 2.26.2