On Fri, Feb 23, 2018 at 02:17:34PM -0600, Jason L Tibbitts III wrote:
> >>>>> "JJ" == Jakub Jelinek <ja...@redhat.com> 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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
