c6/5b1a986ce6e6d02f1ad1ce19dae9ec5751de18

   1 Return-Path: <bart@ursys.com.au>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id B828E431FAF\r
   6         for <notmuch@notmuchmail.org>; Wed, 22 Aug 2012 18:21:59 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: 0\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]\r
  12         autolearn=disabled\r
  13 Received: from olra.theworths.org ([127.0.0.1])\r
  14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15         with ESMTP id d1gYuJfOjMkE for <notmuch@notmuchmail.org>;\r
  16         Wed, 22 Aug 2012 18:21:59 -0700 (PDT)\r
  17 Received: from bit.local (that.urnet.com.au [203.7.149.1])\r
  18         by olra.theworths.org (Postfix) with ESMTP id 8256F431FAE\r
  19         for <notmuch@notmuchmail.org>; Wed, 22 Aug 2012 18:21:58 -0700 (PDT)\r
  20 Received: by bit.local (Postfix, from userid 501)\r
  21         id 1E2AF12AAFC9; Thu, 23 Aug 2012 11:21:55 +1000 (EST)\r
  22 From: "Bart Bunting" <bart@ursys.com.au>\r
  23 To: Austin Clements <amdragon@MIT.EDU>\r
  24 Subject: Re: Errors after upgrade to 0.14\r
  25 In-Reply-To: <20120823010922.GV11179@mit.edu>\r
  26 References: <m2mx1m8pp3.fsf@ursys.com.au> <20120823004117.GT11179@mit.edu>\r
  27         <20120823010922.GV11179@mit.edu>\r
  28 User-Agent: Notmuch/0.13.2+128~g369b28d (http://notmuchmail.org)\r
  29         Emacs/24.2.50.1 (i386-apple-darwin12.0.0)\r
  30 Date: Thu, 23 Aug 2012 11:21:54 +1000\r
  31 Message-ID: <m2mx1m9zd9.fsf@ursys.com.au>\r
  32 MIME-Version: 1.0\r
  33 Content-Type: text/plain\r
  34 Cc: notmuch@notmuchmail.org\r
  35 X-BeenThere: notmuch@notmuchmail.org\r
  36 X-Mailman-Version: 2.1.13\r
  37 Precedence: list\r
  38 List-Id: "Use and development of the notmuch mail system."\r
  39         <notmuch.notmuchmail.org>\r
  40 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  41         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  42 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  43 List-Post: <mailto:notmuch@notmuchmail.org>\r
  44 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  45 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  46         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  47 X-List-Received-Date: Thu, 23 Aug 2012 01:21:59 -0000\r
  48 \r
  49 Hi Austin,\r
  50 \r
  51 I applied the patch and this error was from after that.\r
  52 \r
  53 The way it was triggered was by hitting 'a' to archive a message in the\r
  54 search view.\r
  55 \r
  56 >From what I can tell it's just the xapian error and there is nothing\r
  57 about json.  Hope it means more to you.\r
  58 \r
  59 Debugger entered--Lisp error: (error "A Xapian exception occurred opening database: Unable to get write lock on /Users/bart/mail/.notmuch/xapian: already locked")\r
  60   ad-Orig-signal(error ("A Xapian exception occurred opening database: Unable to get write lock on /Users/bart/mail/.notmuch/xapian: already locked"))\r
  61   signal(error ("A Xapian exception occurred opening database: Unable to get write lock on /Users/bart/mail/.notmuch/xapian: already locked"))\r
  62   ad-Orig-error("A Xapian exception occurred opening database: Unable to get write lock on /Users/bart/mail/.notmuch/xapian: already locked")\r
  63   apply(ad-Orig-error "A Xapian exception occurred opening database: Unable to get write lock on /Users/bart/mail/.notmuch/xapian: already locked")\r
  64   error("A Xapian exception occurred opening database: Unable to get write lock on /Users/bart/mail/.notmuch/xapian: already locked")\r
  65   notmuch-call-notmuch-process("tag" "-inbox" "--" "thread:00000000000225c8")\r
  66   apply(notmuch-call-notmuch-process "tag" ("-inbox" "--" "thread:00000000000225c8"))\r
  67   notmuch-tag("thread:00000000000225c8" ("-inbox"))\r
  68   notmuch-search-tag-region(800 800 ("-inbox"))\r
  69   notmuch-search-tag(("-inbox"))\r
  70   ad-Orig-notmuch-search-archive-thread()\r
  71   notmuch-search-archive-thread()\r
  72   call-interactively(notmuch-search-archive-thread nil nil)\r
  73 \r
  74 \r
  75 Kind regards\r
  76 \r
  77 Austin Clements <amdragon@MIT.EDU> writes:\r
  78 \r
  79 > Quoth myself on Aug 22 at  8:41 pm:\r
  80 >> Quoth Bart Bunting on Aug 23 at  9:36 am:\r
  81 >> > Good morning,\r
  82 >> > \r
  83 >> > After upgrading to notmuch 014 I am seeing the following messages appear\r
  84 >> > in the messages buffer.\r
  85 >> > \r
  86 >> > error in process filter: byte-code: Wrong type argument: number-or-marker-p, nil\r
  87 >> > error in process filter: Wrong type argument: number-or-marker-p, nil\r
  88 >> > \r
  89 >> > I am also getting a repeating message in the minibuffer (I think) which\r
  90 >> > says something like "json read tail error".  Sorry that I am not more\r
  91 >> > specific as I use emacspeak and this message appears to repeat many\r
  92 >> > times interupting speech so I am not 100% sure of what it exactly says.\r
  93 >> \r
  94 >> This is probably "json-readtable-error", which is, unfortunately,\r
  95 >> about the most generic error the JSON parser can give.\r
  96 >> \r
  97 >> > My gut feeling is that it is happening when notmuch is updating the\r
  98 >> > database or something.\r
  99 >> > \r
 100 >> > Is this expected behaviour?  It is particularly annoying for me as it\r
 101 >> > sends the speech synth crazy and crashes it for a period of about 30\r
 102 >> > seconds.\r
 103 >> > \r
 104 >> > If it is expected then I will try and find a way to prevent emacspeak\r
 105 >> > from trying to read it.\r
 106 >> \r
 107 >> This is definitely not expected behavior.  Does this happen when\r
 108 >> you're searching for messages or when you're viewing a thread?  Can\r
 109 >> you give any more details on what you're doing when you get this\r
 110 >> error?\r
 111 >> \r
 112 >> Try doing M-x toggle-debug-on-error and then triggering the error.\r
 113 >> Hopefully Emacs will give you a buffer with a backtrace that will give\r
 114 >> us a better idea of where this is happening.\r
 115 >\r
 116 > Actually, I might know what's going on here.  Based on your suspicion\r
 117 > about notmuch updating the database and assuming that this happens in\r
 118 > the search buffer, I think the parser error recovery code is leaving\r
 119 > the parser in a slightly invalid state, which causes the next\r
 120 > invocation to think it can consume more data when there is no more\r
 121 > data to consume.  I would expect that to give at most one readtable\r
 122 > error, but maybe there's something I'm overlooking.\r
 123 >\r
 124 > Could you try the following one line patch?\r
 125 >\r
 126 > diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el\r
 127 > index 900235b..a09c0f6 100644\r
 128 > --- a/emacs/notmuch-lib.el\r
 129 > +++ b/emacs/notmuch-lib.el\r
 130 > @@ -375,7 +375,7 @@ resynchronize after an error by moving point."\r
 131 >  \r
 132 >    (if (eq (notmuch-json-next jp) 'value)\r
 133 >        ;; We're already at a value\r
 134 > -      nil\r
 135 > +      (if (eobp) 'retry nil)\r
 136 >      ;; Drive the state toward 'expect-value\r
 137 >      (skip-chars-forward " \t\r\n")\r
 138 >      (or (when (eobp) 'retry)\r
 139 >\r
 140 Bart\r
 141 -- \r
 142 Bart Bunting - Engineering Manager - URSYS\r
 143 459-461 Parramatta Rd. Leichhardt  NSW  2040  Australia\r
 144 Ph:           +61 2 8745 2811\r
 145 Mbl:          0409 560 005\r