Thanks for the backtrace. Apparantly, notmuch trigers a xapian bug that it hasn't triggered before. But before reassigning, could you try the koji scratch build of notmuch-0.29.2? It contains seemingly unrelated fixes, but who knows:

https://koji.fedoraproject.org/koji/taskinfo?taskID=38686331

This message is a reminder that Fedora 29 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '29'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 29 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Although it seems to work faster(the feeling) the new version 0.29.2-1 still crashes.

gdb --args notmuch tag +list +ccamp -inbox to:ccamp and not tag:ccamp
GNU gdb (GDB) Fedora 8.3-6.fc30
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from notmuch...
Reading symbols from /usr/lib/debug/usr/bin/notmuch-0.29.2-1.fc30.x86_64.debug...
(gdb) r
Starting program: /usr/bin/notmuch tag +list +ccamp -inbox to:ccamp and not tag:ccamp
Missing separate debuginfos, use: dnf debuginfo-install glibc-2.29-22.fc30.x86_64

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7a862b8 in AndNotPostList::get_weight (this=<optimized out>) at matcher/andnotpostlist.cc:177
177	    RETURN(l->get_weight());
Missing separate debuginfos, use: dnf debuginfo-install glib2-2.60.7-1.fc30.x86_64 gmime30-3.2.3-2.fc30.x86_64 gpgme-1.12.0-1.fc30.x86_64 libassuan-2.5.2-2.fc30.x86_64 libblkid-2.33.2-2.fc30.x86_64 libffi-3.1-19.fc30.x86_64 libgcc-9.2.1-1.fc30.x86_64 libgpg-error-1.33-2.fc30.x86_64 libmount-2.33.2-2.fc30.x86_64 libselinux-2.9-3.1.fc30.x86_64 libstdc++-9.2.1-1.fc30.x86_64 libtalloc-2.1.16-1.fc30.x86_64 libuuid-2.33.2-2.fc30.x86_64 libxcrypt-4.4.10-1.fc30.x86_64 pcre-8.43-2.fc30.x86_64 pcre2-10.33-14.fc30.x86_64 zlib-1.2.11-18.fc30.x86_64
(gdb) bt
#0  0x00007ffff7a862b8 in AndNotPostList::get_weight() const (this=<optimized out>) at matcher/andnotpostlist.cc:177
#1  0x00007ffff7a89d06 in SelectPostList::get_weight() const (this=0x4c5240) at matcher/selectpostlist.h:61
#2  0x00007ffff7a9162a in MultiMatch::get_mset(unsigned int, unsigned int, unsigned int, Xapian::MSet&, Xapian::Weight::Internal&, Xapian::MatchDecider const*, Xapian::KeyMaker const*)
    (this=0x7fffffffc9f0, first=0, maxitems=<optimized out>, check_at_least=109563, mset=..., stats=..., mdecider=0x0, sorter=0x0) at matcher/multimatch.cc:625
#3  0x00007ffff79a70e6 in Xapian::Enquire::Internal::get_mset(unsigned int, unsigned int, unsigned int, Xapian::RSet const*, Xapian::MatchDecider const*) const () at api/omenquire.cc:572
#4  0x00007ffff79a7359 in Xapian::Enquire::get_mset(unsigned int, unsigned int, unsigned int, Xapian::RSet const*, Xapian::MatchDecider const*) const
    (this=this@entry=0x7fffffffcbd8, first=first@entry=0, maxitems=<optimized out>, check_at_least=check_at_least@entry=0, rset=rset@entry=0x0, mdecider=0x0) at api/omenquire.cc:937
#5  0x00007ffff7f68da0 in _notmuch_query_search_documents(notmuch_query_t*, char const*, notmuch_messages_t**) (query=0x45b190, type=<optimized out>, out=0x7fffffffcd20) at lib/query.cc:346
#6  0x0000000000419468 in tag_query
    (ctx=ctx@entry=0x44a970, notmuch=notmuch@entry=0x436160, query_string=0x46a2d0 "( to:ccamp and not tag:ccamp ) and (not tag:list or not tag:ccamp or tag:inbox)", tag_ops=tag_ops@entry=0x456990, flags=(TAG_FLAG_MAILDIR_SYNC | TAG_FLAG_PRE_OPTIMIZED), flags@entry=TAG_FLAG_MAILDIR_SYNC) at notmuch-tag.c:124
#7  0x00000000004199d2 in notmuch_tag_command (config=0x44a970, argc=<optimized out>, argv=0x7fffffffd2f0) at notmuch-tag.c:279
#8  0x0000000000409efb in main (argc=9, argv=0x7fffffffd2e8) at notmuch.c:502

OK, thanks for checking.

I'll reassign to xapian-core since the crash occurs there. It might still be the case that notmuch sends unexpected input.

Is there any chance that you can produce a minimal reproducer which you can share? I.e., on a copy of the notmuch db, reduce it to something you share?

Note that the produced query string is somewhat redundant:

"( to:ccamp and not tag:ccamp ) and (not tag:list or not tag:ccamp or tag:inbox)"

If the first parentheses is true, then so is "not tag:ccamp" and therefore the second parentheses. Do the following crash:

notmuch search "( to:ccamp and not tag:ccamp ) and (not tag:list or not tag:ccamp or tag:inbox)"

notmuch search "( to:ccamp and not tag:ccamp )"

They should give the same result.

(In reply to Michael J Gruber from comment #4)
> 
> Is there any chance that you can produce a minimal reproducer which you can
> share? I.e., on a copy of the notmuch db, reduce it to something you share?

How can I do that? Since most of the bad cases are from public mailing lists, I don't have any issue as long as you give me some instructions.

> 
> Note that the produced query string is somewhat redundant:
> 
> "( to:ccamp and not tag:ccamp ) and (not tag:list or not tag:ccamp
> or tag:inbox)"
> 
> If the first parentheses is true, then so is "not tag:ccamp" and therefore
> the second parentheses. Do the following crash:
> 
> notmuch search "( to:ccamp and not tag:ccamp ) and (not tag:list or
> not tag:ccamp or tag:inbox)"
> 
> notmuch search "( to:ccamp and not tag:ccamp )"
> 
> They should give the same result.

You have a point here, but the command line invocation is:

notmuch tag +list +ccamp -inbox to:ccamp and not tag:ccamp

and I don't know why it is transformed that way.

The work around to avoid the crash is to remove the latest "and not tag:ccamp"

Please check for duplicates first. See details for how to test the update already in testing

*** This bug has been marked as a duplicate of bug 1766219 ***

Sorry for the duplication but with a first search no entry showed up for notmuch.

Nevertheless, I have tested the new xapian-core and the problem does not appears any more.

Thank you for the effort.