Re: BUG #15133: make check fails - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #15133: make check fails
Date
Msg-id 22725.1522250569@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #15133: make check fails  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: BUG #15133: make check fails
Re: BUG #15133: make check fails
List pgsql-bugs
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> I'm not sure of the support status for Solaris 11.  We don't have any
> buildfarm member for that, much less the 11.4 beta.  Maybe this is a
> problem in the OS, or the compiler?  I can't see siglongjmp() failing in
> this way being a Postgres bug, frankly ...

I think the key thing in this stack trace is

>> ffffffe0b083a921 postgres`errfinish+0x260(0, 0, 0, 1fff248dfa8960, 0, 20000034b4a85be0)
>> ffffffe0b083aa21 check_stack_depth+0x114(20000034b4a86320, 20000034b4a86520, 20000034b4a865a0, 0, 800000, 0)
>> ffffffe0b083aaf1 transformExprRecurse+0x44(20000034b4a865a0, 20000034b4a86320, 0, 0, 0, 0)

That is, we died while trying to throw an error out of check_stack_depth,
which suggests that we were in recursion trouble.  Either that or
something's broken about the stack depth test.  The most plausible theory
about why siglongjmp failed is that it SIGSEGV'd against the end of the
stack, which would also imply something's broken about the stack depth
test, because it ought to trigger well before we actually run out of
stack.

Does Solaris even have getrlimit(RLIMIT_STACK)?  If so, does it tell the
truth on this beta version?

It'd be interesting to know which regression test query failed.  If it was
anything other than the intentional infinite_recurse call, then there's
something else wrong too.

            regards, tom lane


pgsql-bugs by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: BUG #15133: make check fails
Next
From: Alvaro Herrera
Date:
Subject: Re: BUG #15133: make check fails