https://bugzilla.redhat.com/show_bug.cgi?id=2069264
--- Comment #18 from Michael J Gruber <mjg(a)fedoraproject.org> ---
Very keen and helpful observation, and inline with the original stack trace,
since do_search_threads() is used in these two modes only. (I originally looked
deeper down in the stack/lines up.)
At this point we can take this to the notmuch-devel list or continue here - I'm
sure it's no package problem nor a regression. I suspect a problem in the
database which, arguably, notmuch could deal with in a better way.
Things you could try:
`notmuch search --exclude=false` could avoid the codepath which calls into
notmuch_message_get_tags(), but the real problem might show up later, as it did
with my first patch (which made one codepath behave well).
`NOTMUCH_DEBUG_QUERY=1 notmuch search` will output the underlying Xapian
queries which notmuch uses. In particular, they are different for different
output modes and might indicate whether there are suspicious Terms or thread
entries (G...).
From that we could delve into the Xapian db. I did this once but would have to
brush up on my Xapian-foo.
Possible solution for the suspected db problem:
`notmuch reindex` will probably run into the same segfault before reindexing
the message ... So, alternatively: Backup the tags (selective dump), move the
message file away from the mail tree, `notmuch new` to purge it from the db,
then move it back or `notmuch insert` it, possibly followed up by restoring the
tags.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2069264