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>