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