I'm sorry, for the first time in decades I actually hit the send key sequence (Ctrl-C Ctrl-C) accidentally. >>>>> "JJ" == Jakub Jelinek <jakub@xxxxxxxxxx> 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 https://cyrusimap.org/imap/reference/manpages/systemcommands/squatter.html 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 output. 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 export CYRUS_USER=$USER export LD_LIBRARY_PATH=/builddir/build/BUILDROOT/cyrus-imapd-3.0.5-4.fc29.x86_64/usr/lib64 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: "/builddir/build/BUILDROOT/cyrus-imapd-3.0.5-4.fc28.x86_64/usr/sbin/squatter" "-C" "/builddir/build/BUILD/cyrus-imapd-3.0.5/cassandane/work/2322151/conf/imapd.conf" 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 work/2322151/conf/imapd.conf 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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
