Re: Failing test cases

diff --git a/e4/59346b235e6882a138d359409e5bf2a345f879 b/e4/59346b235e6882a138d359409e5bf2a345f879
new file mode 100644 (file)
index 0000000..3df4df0
--- /dev/null
+++ b/e4/59346b235e6882a138d359409e5bf2a345f879
@@ -0,0 +1,130 @@
+Return-Path: <cworth@cworth.org>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+       by olra.theworths.org (Postfix) with ESMTP id 53EF74196F2\r
+       for <notmuch@notmuchmail.org>; Tue,  4 May 2010 12:09:58 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -2.89\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-2.89 tagged_above=-999 required=5\r
+       tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, T_MIME_NO_TEXT=0.01]\r
+       autolearn=ham\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+       by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+       with ESMTP id RPqWUhgByAm5; Tue,  4 May 2010 12:09:57 -0700 (PDT)\r
+Received: from yoom.home.cworth.org (localhost [127.0.0.1])\r
+       by olra.theworths.org (Postfix) with ESMTP id 66BCF431FC1;\r
+       Tue,  4 May 2010 12:09:57 -0700 (PDT)\r
+Received: by yoom.home.cworth.org (Postfix, from userid 1000)\r
+       id 0D92B568E09; Tue,  4 May 2010 12:09:57 -0700 (PDT)\r
+From: Carl Worth <cworth@cworth.org>\r
+To: Olly Betts <olly@survex.com>, notmuch@notmuchmail.org\r
+Subject: Re: Failing test cases\r
+In-Reply-To: <87zl0fmst4.fsf@yoom.home.cworth.org>\r
+References: <20100425001743.GA9293@jdc.jasonjgw.net>\r
+       <20100428002615.GA10022@jdc.jasonjgw.net>\r
+       <87wrvsqti6.fsf@yoom.home.cworth.org>\r
+       <20100428012547.GA680@jdc.jasonjgw.net>\r
+       <slrnhtkc84.pf1.olly@msgid.survex.com>\r
+       <87zl0fmst4.fsf@yoom.home.cworth.org>\r
+User-Agent: Notmuch/0.3-7-g2baa576 (http://notmuchmail.org) Emacs/23.1.1\r
+       (i486-pc-linux-gnu)\r
+Date: Tue, 04 May 2010 12:09:56 -0700\r
+Message-ID: <87wrvjmqkb.fsf@yoom.home.cworth.org>\r
+MIME-Version: 1.0\r
+Content-Type: multipart/signed; boundary="=-=-=";\r
+       micalg=pgp-sha1; protocol="application/pgp-signature"\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+       <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Tue, 04 May 2010 19:09:58 -0000\r
+\r
+--=-=-=\r
+Content-Transfer-Encoding: quoted-printable\r
+\r
+On Tue, 04 May 2010 11:21:27 -0700, Carl Worth <cworth@cworth.org> wrote:\r
+> I installed Xapian 1.0.20 (from the libxapian-dev package in sid) and am\r
+> now getting this failure.\r
+>=20\r
+> I'm investigating more closely now, but I thought I'd at least share\r
+> that much information.\r
+\r
+Here are my conclusions based on some additional investigation:\r
+\r
+What's happening here is that notmuch is creating a Xapian TermIterator,\r
+iterating over some of the results, and then modifying the database such\r
+that the terms being iterated over are affected. Specifically, in this\r
+test case, notmuch is inserting a new term before the term being pointed\r
+at by the iterator.\r
+\r
+With Xapian 1.0.18 incrementing the iterator from this state causes it\r
+to point to the next term. However, with Xapian 1.0.20 this same\r
+increment causes the iterator to point at the same term again.\r
+\r
+I was able to put a little workaround into notmuch-new.c that avoids the\r
+bug (see below). But this isn't entirely satisfactory for several\r
+reasons:\r
+\r
+1. We need to know what the intended semantics of the Xapian iterators\r
+   really are. If this behavior is just a bug in Xapian, then that\r
+   should be fixed.\r
+\r
+   But if the iterators are to have explicitly undefined behavior in\r
+   cases like this, then notmuch is going to need to carefully copy\r
+   contents out of Xapian iterators when creating notmuch iterators (at\r
+   some performance cost).\r
+\r
+2. Working around the bug in notmuch-new.c doesn't fix the notmuch\r
+   library itself, (so that python bindings, etc. will remain\r
+   broken). So we really do need a lower-level fix for this.\r
+\r
+To properly do the lower-level fix for (2), we'll need to know the\r
+answer to (1). Olly, do you have an answer on the intended semantics of\r
+Xapian iterators?\r
+\r
+=2DCarl\r
+\r
+diff --git a/notmuch-new.c b/notmuch-new.c\r
+index 8818728..928bb94 100644\r
+=2D-- a/notmuch-new.c\r
++++ b/notmuch-new.c\r
+@@ -380,7 +380,11 @@ add_files_recursive (notmuch_database_t *notmuch,\r
+       if (notmuch_filenames_valid (db_files) &&\r
+           strcmp (notmuch_filenames_get (db_files), entry->d_name) =3D=3D 0)\r
+       {\r
+=2D        notmuch_filenames_move_to_next (db_files);\r
++          while (notmuch_filenames_valid (db_files) &&\r
++                 strcmp (notmuch_filenames_get (db_files), entry->d_name) <=3D 0)\r
++          {\r
++              notmuch_filenames_move_to_next (db_files);\r
++          }\r
+           continue;\r
+       }\r
+=20\r
+\r
+\r
+=2D-=20\r
+carl.d.worth@intel.com\r
+\r
+--=-=-=\r
+Content-Type: application/pgp-signature\r
+\r
+-----BEGIN PGP SIGNATURE-----\r
+Version: GnuPG v1.4.10 (GNU/Linux)\r
+\r
+iD8DBQFL4HEE6JDdNq8qSWgRAnlcAJ9XL4VqTAbkPVzX8xTDGM3G2X0ZeQCffdux\r
+m3fmvhDiXuJHbO7lUKue1mw=\r
+=X3CT\r
+-----END PGP SIGNATURE-----\r
+--=-=-=--\r