On Fri, Feb 23, 2018 at 02:17:34PM -0600, Jason L Tibbitts III wrote: > >>>>> "JJ" == Jakub Jelinek <jakub@xxxxxxxxxx> writes: > > JJ> Well, I'm seeing > [...] > > So that's the first of the two test suites, which I've seen fail before > but I haven't invested any time into debugging it. It's completely > unrelated to any of the failures I'm talking about. > > You can just remove or comment the line "make check || exit 1" in the > spec to skip that test suite and get down to the one that crashes. > > JJ> Does it need networking outside of the mock (i.e. shall I retry with > JJ> --enable-networking)? > > There should be no need; it certainly doesn't need networking. That's > just a cunit-based test suite and outside of a couple of cases where I > was randomly trying things to get better debugging for the unwinder > segfault at hand, I've not had any real problems with it. Strangely, --enable-network to mock was really needed so that the first testsuite passes. I can now get the coredumps, but I'm afraid I really need a way to reproduce it under gdb, from the core dump there isn't sufficient information available. So, what is this squatter process about, with what command line options is it invoked, how does it interact with other processes, is it single-threaded? What I can see is that the exc passed to _Unwind_Resume points to some memory inside of the xapian_dbw_open C++ function's stack frame which indeed contains multiple try/catch blocks, even nested ones; but I find it strange that _Unwind_Exception objects would be on the stack, they should be in malloced objects (at the end of __cxa_exception e.g. for C++ exceptions), or come from the emergency pool if malloc would fail (unlikely in this case). The _Unwind_Exception contains completely bogus values not just in one field, but in all of them. Jakub _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
