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