On Sat, 28 Nov 2009 05:40:13 -0400, David Bremner <bremner at pivot.cs.unb.ca>
wrote:
> Now it seems that any search that is non-empty (i.e. matches
> something) crashes with a duplicate In-Reply-To ID. This is in git
> revision 92c4dcc (although it was the same yesterday). The oddest
> thing is that the second message-id is a common English word.
...
> Internal error: Message 877htzhn9e.wl%jemarch at gnu.org has duplicate
> In-Reply-To IDs: 1e5bcefd0911081424p12eb6fa9te57ff4cfeb83fcdd at
> mail.gmail.com and data
> (lib/message.cc:326).
Thanks David,
I replicated this without any difficulty. And the fix was to just
correct a stupid mistake on my part. The only reason I hadn't noticed
this myself earlier is that I've been doing debug builds with:
make CFLAGS="-g -DDEBUG"
instead of:
make CFLAGS="-g -DDEBUG" CXXFLAGS="-g -DDEBUG"
If we can, I'd like to see about making the former work, to avoid hiding
things like this in the future.
> At the moment I don't have any real good ideas for how to debug this
> (or any real familiarity with notmuch internals). I put a test corpus
> of messages (all from public mailing lists) at
Before I realized how easy the bug was to replicate and fix, I was going
to give a couple of debugging ideas here. I guess I'll briefly mention
things anyway.
The core of what we store in the database for each message is a single
list of "terms", (each a string of text). We use different terms for
different purposes by prefixing some with particular sub-strings. See
the large comment at the top of lib/database.cc for some details on
this.
So if there *were* an actual case of a duplicate In-Reply-To term here,
the first thing to do would be to inspect the actual terms in the
database for the document of the message of interest. Up until now, what
I've been using for this is a little utility I wrote called
xapian-dump. It exists deep in the code history of notmuch. So one could
use git log to find the commit that removed it and then check out the
commit before that to get the utility.
But xapian-dump is pretty dumb and all it does is dump all terms from
all documents in the database, (it also dumps all the data and values
