Errors after upgrade to 0.14

Errors after upgrade to 0.14

[Bart Bunting]

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.

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.

  

Kind regards

Bart
-- 
Bart Bunting - Engineering Manager - URSYS
459-461 Parramatta Rd. Leichhardt  NSW  2040  Australia
Ph:           +61 2 8745 2811
Mbl:          0409 560 005

Re: Errors after upgrade to 0.14

[Austin Clements]

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.

Re: Errors after upgrade to 0.14

[Austin Clements]

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)

Re: Errors after upgrade to 0.14

[Bart Bunting]

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)
>
Bart
-- 
Bart Bunting - Engineering Manager - URSYS
459-461 Parramatta Rd. Leichhardt  NSW  2040  Australia
Ph:           +61 2 8745 2811
Mbl:          0409 560 005

Re: Errors after upgrade to 0.14

[Austin Clements]

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)
> >

Re: Errors after upgrade to 0.14

[Bart Bunting]

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 <amdragon@MIT.EDU> 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 <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)
>> >
Bart
-- 
Bart Bunting - Engineering Manager - URSYS
459-461 Parramatta Rd. Leichhardt  NSW  2040  Australia
Ph:           +61 2 8745 2811
Mbl:          0409 560 005

Re: Errors after upgrade to 0.14

[Bart Bunting]

Ok perhaps this is more helpfull?

Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
  notmuch-search-show-result("tags")
  byte-code("\304\b\305\"\203\306	!\307=\203\310\202Q\303\202Q\304\b\311\"\203D\312	!\304\v\313\"\2030\310\202@\304\v\314\"\203<\315\202@\316\v!\210)\202Q\304\b\317\"\203Q\320	!\210\310\304\207" [notmuch-search-process-state notmuch-search-json-parser done result memql (begin) notmuch-json-begin-compound retry t (result) notmuch-json-read (retry) (end) end notmuch-search-show-result (end) notmuch-json-eof] 3)
  notmuch-search-process-filter(#<process notmuch-search> ", \"tags\": []},\nA Xapian exception occurred performing query: The revision being read has been discarded - you should call Xapian::Database::reopen() and retry the operation\nQuery string was: thread:0000000000020a59\n{\"thread\": \"000000000001fd19\", \"timestamp\": 0, \"date_relative\": \"1970-01-01\", \"matched\": 0, \"total\": 0, \"authors\": \"\", \"subject\": \"\", \"tags\": []},\nA Xapian exception occurred performing query: The revision being read has been discarded - you should call Xapian::Database::reopen() and retry the operation\nQuery string was: thread:0000000000020a57\n{\"thread\": \"0000000000020a59\", \"timestamp\": 0, \"date_relative\": \"1970-01-01\", \"matched\": 0, \"total\": 0, \"authors\": \"\", \"subject\": \"\", \"tags\": []},\nA Xapian exception occurred performing query: The revision being read has been discarded - you should call Xapian::Database::reopen() and retry the operation\nQuery string was: thread:0000000000020a57\n{\"thread\": \"0000000000020a57\", \"timestamp\": 0, \"date_relative\": \"1970-01-01\", \"matched\": 0, \"total\": 0, \"authors\": ")
  recursive-edit()
  debug(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:0000000000022288")
  apply(notmuch-call-notmuch-process "tag" ("-inbox" "--" "thread:0000000000022288"))
  notmuch-tag("thread:0000000000022288" ("-inbox"))
  notmuch-search-tag-region(202 202 ("-inbox"))
  notmuch-search-tag(("-inbox"))
  ad-Orig-notmuch-search-archive-thread()
  notmuch-search-archive-thread()
  call-interactively(notmuch-search-archive-thread nil nil)
  recursive-edit()
  debug(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")


Kind regards

Bart

Re: Errors after upgrade to 0.14

[Austin Clements]

Fun.  It looks like several things are colluding to cause problems
here.  The root problem is still concurrent database access, judging
by the error messages embedded in the string passed to
notmuch-search-process-filter, but it's being handled poorly at
several layers.  First, _notmuch_thread_create in the library doesn't
notice when notmuch_query_search_messages fails, so it constructs an
empty thread object, rather than indicating failure, which
notmuch-search.c dutifully emits.  But by that point the damage has
already been done by the error printed deep in the bowels of the
library.  Somehow that error message is tripping up the incremental
parser (exactly how I'm unclear on) and causing it to read the string
"tags" as a list-level JSON object, which it then passes to
notmuch-search-show-result as a result object.  Since it's not a
result object, plist-get returns nil, which causes = to raise the
error.

This is probably a bug in the error recovery of the incremental JSON
parser (or its use in search-mode), since the output below looks clean
enough that it *should* be able to catch the error and resynchronize.

Quoth Bart Bunting on Aug 23 at 11:49 am:
> Ok perhaps this is more helpfull?
> 
> Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
>   notmuch-search-show-result("tags")
>   byte-code("\304\b\305\"\203\306	!\307=\203\310\202Q\303\202Q\304\b\311\"\203D\312	!\304\v\313\"\2030\310\202@\304\v\314\"\203<\315\202@\316\v!\210)\202Q\304\b\317\"\203Q\320	!\210\310\304\207" [notmuch-search-process-state notmuch-search-json-parser done result memql (begin) notmuch-json-begin-compound retry t (result) notmuch-json-read (retry) (end) end notmuch-search-show-result (end) notmuch-json-eof] 3)
>   notmuch-search-process-filter(#<process notmuch-search> ", \"tags\": []},\nA Xapian exception occurred performing query: The revision being read has been discarded - you should call Xapian::Database::reopen() and retry the operation\nQuery string was: thread:0000000000020a59\n{\"thread\": \"000000000001fd19\", \"timestamp\": 0, \"date_relative\": \"1970-01-01\", \"matched\": 0, \"total\": 0, \"authors\": \"\", \"subject\": \"\", \"tags\": []},\nA Xapian exception occurred performing query: The revision being read has been discarded - you should call Xapian::Database::reopen() and retry the operation\nQuery string was: thread:0000000000020a57\n{\"thread\": \"0000000000020a59\", \"timestamp\": 0, \"date_relative\": \"1970-01-01\", \"matched\": 0, \"total\": 0, \"authors\": \"\", \"subject\": \"\", \"tags\": []},\nA Xapian exception occurred performing query: The revision being read has been discarded - you should call Xapian::Database::reopen() and retry the operation\nQuery string was: thread:0000000000020a57\n{\"thread\": \"0000000000020a57\", \"timestamp\": 0, \"date_relative\": \"1970-01-01\", \"matched\": 0, \"total\": 0, \"authors\": ")
>   recursive-edit()
>   debug(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:0000000000022288")
>   apply(notmuch-call-notmuch-process "tag" ("-inbox" "--" "thread:0000000000022288"))
>   notmuch-tag("thread:0000000000022288" ("-inbox"))
>   notmuch-search-tag-region(202 202 ("-inbox"))
>   notmuch-search-tag(("-inbox"))
>   ad-Orig-notmuch-search-archive-thread()
>   notmuch-search-archive-thread()
>   call-interactively(notmuch-search-archive-thread nil nil)
>   recursive-edit()
>   debug(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")
> 
> 
> Kind regards
> 
> Bart