[notmuch] Segfault searching for tags

[Adrian Perez de Castro]

On Wed, 18 Nov 2009 12:00:10 -0600, Jeffrey wrote:

> Getting the following segfault with 306635c2 on Fedora 12.  Seems to
> be happening with any 'tag:' search that returns results.  For
> example, 'notmuch search tag:inbox' and 'notmuch search tag:unread'
> segfault but 'notmuch search tag:nosuchtag', 'notmuch search
> subject:logwatch' and 'notmuch search video' seem to work fine.
> 
> Core was generated by `/usr/bin/notmuch search --sort=oldest-first tag:inbox'.
> Program terminated with signal 11, Segmentation fault.
> \#0  Xapian::TermIterator::operator* (this=<value optimized out>)
>     at api/omtermlistiterator.cc:78
> 78	    RETURN(internal->get_termname());
> Current language:  auto
> The current source language is "auto; currently c++".

I have hit what I believe is exactly the same problem. In my case, some
results are printed when I execute "notmuch search tag:inbox", and then
the program crashes in the same exact place.

The thing is that in notmuch_message_get_in_reply_to(), line 288, a NULL
instance of Xapian::TermIterator is dereferenced. In my particular case,
the culpript is a cache file of Claws-Mail, as seen in the following GDB
session:

Program received signal SIGSEGV, Segmentation fault.
Xapian::TermIterator::operator* (this=<value optimized out>) at api/omtermlistiterator.cc:78
78   RETURN(internal->get_termname()); Current language:  auto
The current source language is "auto; currently c++".
(gdb) bt
#0  Xapian::TermIterator::operator* (this=<value optimized out>) at api/omtermlistiterator.cc:78
#1  0x000000000040f611 in _notmuch_message_get_in_reply_to(message=0x76dcd0) at lib/message.cc:288
#2  0x0000000000412030 in _resolve_thread_relationships (thread=0x6a8b80) at lib/thread.cc:157
#3  0x0000000000412454 in _notmuch_thread_create (ctx=0x65f1b0, notmuch=0x62d320, thread_id= 0x765530 "01b17ddb4479a0dc0b416bb63b92c43d", query_string=0x65f220 "tag:inbox") at lib/thread.cc:285
#4  0x0000000000411982 in notmuch_query_search_threads (query=0x65f1b0, first=100, max_threads=-1) at lib/query.cc:218
#5  0x000000000040924d in do_search_threads (ctx=0x61f140, query=0x65f1b0, sort=NOTMUCH_SORT_NEWEST_FIRST, first=100, max_threads=-1) at notmuch-search.c:40
#6  0x00000000004097ef in notmuch_search_command (ctx=0x61f140, argc=1, argv=0x7fffffffe188) at notmuch-search.c:164
#7  0x00000000004066f1 in main (argc=3, argv=0x7fffffffe178) at notmuch.c:400
(gdb) frame 1
#1  0x000000000040f611 in _notmuch_message_get_in_reply_to (message=0x76dcd0) at lib/message.cc:288
288	    in_reply_to = *i;
(gdb) p *message
$1 = {notmuch = 0x62d320, doc_id = 1, frozen = 0, message_id = 0x76db60 "", thread_id = 0x0, 
  in_reply_to = 0x0, filename = 0x76dc50 "/home/aperez/.mail/inbox/.claws_cache", message_file = 0x0, 
  replies = 0x76d250, doc = {internal = {dest = 0x76d450}}}

As you can see, there "filename" points to a Claws-Mail cache file, which
is a binary file (I can provide a copy if needed). I suspect that this is
related to the fact that the iterator ends up being NULL somehow.

I will experiment a bit more with this issue -- maybe just avoiding adding
files whose name starts with a dot will suffice as temporary fix.

Cheers,

-- 
Adrian Perez de Castro <aperez at igalia.com>
Igalia - Free Software Engineering
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091119/5a6cbd02/attachment.pgp>