I'm sorry, for the first time in decades I actually hit the send
key sequence (Ctrl-C Ctrl-C) accidentally.

>>>>> "JJ" == Jakub Jelinek <ja...@redhat.com> writes:

JJ> Strangely, --enable-network to mock was really needed so that the
JJ> first testsuite passes.

That's absolutely bizarre.

JJ> I can now get the coredumps, but I'm afraid I really need a way to
JJ> reproduce it under gdb, from the core dump there isn't sufficient
JJ> information available.

I just now found a way.  See below.

JJ> So, what is this squatter process about, with what command line
JJ> options is it invoked, how does it interact with other processes, is
JJ> it single-threaded?

It creates various search indices for the IMAP server (which is why it
wraps Xapian).  The manpage is available from
Technically the test suite simply creates the conditions for it to do
its work (in a randomly named directory) and then calls squatter
directly.  You should be able to see the arguments in the test suite's

You can get down into the mock chroot and run tests manually:

mock -r fedora-rawhide-x86_64 --shell

and then enter:

su - mockbuild
cd /builddir/build/BUILD/cyrus-imapd-3.0.5/cassandane
rm -rf work; mkdir work
./testrunner.pl -vvv -f pretty SearchFuzzy.xapianv2

(You may have to adjust LD_LIBRARY_PATH there; using a glob fails to
work for me for reasons I don't understand.)

That will run just one test.  Down in the log you'll see something like:

=====> Instance[1506] Running: 

A bit further you see the output from that process:

2322151/squatter[50141]: SQL backend defaulting to engine 'pgsql'
2322151/squatter[50141]: indexing mailboxes
2322151/squatter[50141]: indexing mailbox user.cassandane...

and at that point it segfaults.

If at this point you "rm -rf work/224058I1/search" (to clear out the
partially created search database) and then run:

/builddir/build/BUILDROOT/cyrus-imapd-3.0.5-4.fc28.x86_64/usr/sbin/squatter -C 

you should see the same segfault.  For me it does still segfault when
run under gdb, though you will have to delete that "search" directory
each time or the process won't fail.

JJ> What I can see is that the exc passed to _Unwind_Resume points to
JJ> some memory inside of the xapian_dbw_open C++ function's stack frame
JJ> which indeed contains multiple try/catch blocks, even nested ones;

That's about as far as I have been able to comprehend.

Just to be sure, I have done builds with fedora-rpm-macros and glibc
rolled back to the versions January 21 (the last successful koschei
build) and sadly things still fail in the same way.

 - J<
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Reply via email to