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 0F333431FAF for ; Wed, 22 Aug 2012 18:43:25 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 K7t5v14F3s6x for ; Wed, 22 Aug 2012 18:43:24 -0700 (PDT) Received: from bit.local (that.urnet.com.au [203.7.149.1]) by olra.theworths.org (Postfix) with ESMTP id 0FF95431FAE for ; Wed, 22 Aug 2012 18:43:24 -0700 (PDT) Received: by bit.local (Postfix, from userid 501) id 1305112AB2AA; Thu, 23 Aug 2012 11:43:19 +1000 (EST) From: "Bart Bunting" To: Austin Clements Subject: Re: Errors after upgrade to 0.14 In-Reply-To: <20120823013412.GX11179@mit.edu> References: <20120823004117.GT11179@mit.edu> <20120823010922.GV11179@mit.edu> <20120823013412.GX11179@mit.edu> User-Agent: Notmuch/0.13.2+128~g369b28d (http://notmuchmail.org) Emacs/24.2.50.1 (i386-apple-darwin12.0.0) Date: Thu, 23 Aug 2012 11:43:19 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Cc: notmuch@notmuchmail.org 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: Thu, 23 Aug 2012 01:43:25 -0000 Austin, I agree, it appears to be the normal locking issue. That poses a problem but one I'm used to. I was doing an archive when I hit the other error as well. I just got a debug traceback when entering the inbox from the hello screen. Unfortunately it locked up my entire emacs and had to kill the process. I'll keep trying until I get something more helpfull. Cheers Bart Austin Clements writes: > This looks like a different error from the one in your original email. > Was the original error also triggered by hitting 'a'? > > This error is definitely from simultaneous access to the database and > is expected. But this has been a problem since the dawn of notmuch > and shouldn't have started just with 0.14 (unless we did something to > make it worse?). I do have some experimental patches that fix the > database locking issues if it's turning out to be a serious problem > for you, but the fix introduces its own issues. > > Quoth Bart Bunting on Aug 23 at 11:21 am: >> Hi Austin, >> >> I applied the patch and this error was from after that. >> >> The way it was triggered was by hitting 'a' to archive a message in the >> search view. >> >> From what I can tell it's just the xapian error and there is nothing >> about json. Hope it means more to you. >> >> Debugger entered--Lisp error: (error "A Xapian exception occurred opening database: Unable to get write lock on /Users/bart/mail/.notmuch/xapian: already locked") >> ad-Orig-signal(error ("A Xapian exception occurred opening database: Unable to get write lock on /Users/bart/mail/.notmuch/xapian: already locked")) >> signal(error ("A Xapian exception occurred opening database: Unable to get write lock on /Users/bart/mail/.notmuch/xapian: already locked")) >> ad-Orig-error("A Xapian exception occurred opening database: Unable to get write lock on /Users/bart/mail/.notmuch/xapian: already locked") >> apply(ad-Orig-error "A Xapian exception occurred opening database: Unable to get write lock on /Users/bart/mail/.notmuch/xapian: already locked") >> error("A Xapian exception occurred opening database: Unable to get write lock on /Users/bart/mail/.notmuch/xapian: already locked") >> notmuch-call-notmuch-process("tag" "-inbox" "--" "thread:00000000000225c8") >> apply(notmuch-call-notmuch-process "tag" ("-inbox" "--" "thread:00000000000225c8")) >> notmuch-tag("thread:00000000000225c8" ("-inbox")) >> notmuch-search-tag-region(800 800 ("-inbox")) >> notmuch-search-tag(("-inbox")) >> ad-Orig-notmuch-search-archive-thread() >> notmuch-search-archive-thread() >> call-interactively(notmuch-search-archive-thread nil nil) >> >> >> Kind regards >> >> Austin Clements writes: >> >> > Quoth myself on Aug 22 at 8:41 pm: >> >> Quoth Bart Bunting on Aug 23 at 9:36 am: >> >> > Good morning, >> >> > >> >> > After upgrading to notmuch 014 I am seeing the following messages appear >> >> > in the messages buffer. >> >> > >> >> > error in process filter: byte-code: Wrong type argument: number-or-marker-p, nil >> >> > error in process filter: Wrong type argument: number-or-marker-p, nil >> >> > >> >> > I am also getting a repeating message in the minibuffer (I think) which >> >> > says something like "json read tail error". Sorry that I am not more >> >> > specific as I use emacspeak and this message appears to repeat many >> >> > times interupting speech so I am not 100% sure of what it exactly says. >> >> >> >> This is probably "json-readtable-error", which is, unfortunately, >> >> about the most generic error the JSON parser can give. >> >> >> >> > My gut feeling is that it is happening when notmuch is updating the >> >> > database or something. >> >> > >> >> > Is this expected behaviour? It is particularly annoying for me as it >> >> > sends the speech synth crazy and crashes it for a period of about 30 >> >> > seconds. >> >> > >> >> > If it is expected then I will try and find a way to prevent emacspeak >> >> > from trying to read it. >> >> >> >> This is definitely not expected behavior. Does this happen when >> >> you're searching for messages or when you're viewing a thread? Can >> >> you give any more details on what you're doing when you get this >> >> error? >> >> >> >> Try doing M-x toggle-debug-on-error and then triggering the error. >> >> Hopefully Emacs will give you a buffer with a backtrace that will give >> >> us a better idea of where this is happening. >> > >> > Actually, I might know what's going on here. Based on your suspicion >> > about notmuch updating the database and assuming that this happens in >> > the search buffer, I think the parser error recovery code is leaving >> > the parser in a slightly invalid state, which causes the next >> > invocation to think it can consume more data when there is no more >> > data to consume. I would expect that to give at most one readtable >> > error, but maybe there's something I'm overlooking. >> > >> > Could you try the following one line patch? >> > >> > diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el >> > index 900235b..a09c0f6 100644 >> > --- a/emacs/notmuch-lib.el >> > +++ b/emacs/notmuch-lib.el >> > @@ -375,7 +375,7 @@ resynchronize after an error by moving point." >> > >> > (if (eq (notmuch-json-next jp) 'value) >> > ;; We're already at a value >> > - nil >> > + (if (eobp) 'retry nil) >> > ;; Drive the state toward 'expect-value >> > (skip-chars-forward " \t\r\n") >> > (or (when (eobp) 'retry) >> > Bart -- Bart Bunting - Engineering Manager - URSYS 459-461 Parramatta Rd. Leichhardt NSW 2040 Australia Ph: +61 2 8745 2811 Mbl: 0409 560 005