Date: Wed, 22 Aug 2012 21:34:12 -0400
From: Austin Clements <amdragon@MIT.EDU>
To: Bart Bunting <bart@ursys.com.au>
Subject: Re: Errors after upgrade to 0.14
Message-ID: <20120823013412.GX11179@mit.edu>
References: <m2mx1m8pp3.fsf@ursys.com.au> <20120823004117.GT11179@mit.edu>
	<20120823010922.GV11179@mit.edu> <m2mx1m9zd9.fsf@ursys.com.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <m2mx1m9zd9.fsf@ursys.com.au>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: notmuch@notmuchmail.org
Precedence: list

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 <amdragon@MIT.EDU> 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)
> >