Re: [HACKERS] initdb failure on Debian sid/mips64el in EventTriggerEndCompleteQuery

[Christoph Berg]

Re: Tom Lane 2017-08-13 <14677.1502638...@sss.pgh.pa.us>
> Christoph Berg  writes:
> > Seems to be a gcc-7 problem affecting several packages on mips64el:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871514
> 
> Hm, unless there is a use of sigsetjmp earlier in that clamav
> routine, I would not assume that that's the same issue.  The bug
> I suspect we are looking at here is very specific to sigsetjmp
> callers: it usually amounts to the compiler unsafely trying to
> use the same temporary location for multiple purposes.

It appears to have been the same issue - non-long ints spilled on the
stack and loaded back as long int:

Changes:
 gcc-7 (7.2.0-3) unstable; urgency=high
 .
   * Update to SVN 20170901 (r251583) from the gcc-7-branch.
 - Fix PR target/81504 (PPC), PR c++/82040.
   * Apply proposed patch for PR target/81803 (James Cowgill), conditionally
 for mips* targets. Closes: #871514.

The package built successfully on mips64el now.

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] initdb failure on Debian sid/mips64el in EventTriggerEndCompleteQuery

[Christoph Berg]

Re: Tom Lane 2017-08-13 <14517.1502638...@sss.pgh.pa.us>
> I suspect you could work around this with
> 
>   boolisCompleteQuery = (context <= PROCESS_UTILITY_QUERY);
> - boolneedCleanup;
> + volatile bool   needCleanup;
>   boolcommandCollected = false;
> 
> If that fixes it, it's definitely a compiler bug.  That function does
> not change needCleanup after the sigsetjmp call, so per POSIX it
> should not have to label the variable volatile.  This is far from
> being the first such bug we've seen though.

In the meantime, gcc-7 is at version 7.2.0-1, so I gave 9.6 on
mips64el a new try. It's still failing at initdb time, and indeed
adding "volatile" makes initdb proceed, but then the rest of the
testsuite fails in various ways:

DETAIL:  Failed process was running: CREATE TABLE enumtest_child (parent 
rainbow REFERENCES enumtest_parent);
DETAIL:  Failed process was running: create table trigtest2 (i int references 
trigtest(i) on delete cascade);
DETAIL:  Failed process was running: CREATE TABLE trunc_b (a int REFERENCES 
truncate_a);
DETAIL:  Failed process was running: CREATE SCHEMA evttrig
CREATE TABLE one (col_a SERIAL PRIMARY KEY, col_b text DEFAULT 
'forty two')
CREATE INDEX one_idx ON one (col_b)
CREATE TABLE two (col_c INTEGER CHECK (col_c > 0) REFERENCES 
one DEFAULT 42);

Hopefully the compiler gets fixed soonish on mips64el...

Thanks for the analysis,
Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] initdb failure on Debian sid/mips64el in EventTriggerEndCompleteQuery

[Tom Lane]

Christoph Berg  writes:
> Seems to be a gcc-7 problem affecting several packages on mips64el:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871514

Hm, unless there is a use of sigsetjmp earlier in that clamav
routine, I would not assume that that's the same issue.  The bug
I suspect we are looking at here is very specific to sigsetjmp
callers: it usually amounts to the compiler unsafely trying to
use the same temporary location for multiple purposes.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] initdb failure on Debian sid/mips64el in EventTriggerEndCompleteQuery

[Tom Lane]

Christoph Berg  writes:
> 10beta3 and 9.6.4 are both failing during initdb on mips64el on
> Debian/sid (unstable):
> All other architectures have succeeded, as well as the 9.6.4 build for
> Debian/stretch (stable) on mips64el. The difference might be the
> compiler version (6.3.0 vs 7.1.0).

It's hard to explain that stack trace other than as a compiler bug.
There shouldn't be any event triggers active here, so 
EventTriggerBeginCompleteQuery should have done nothing and returned
false.  I don't put complete faith in gdb reports of local variable
values, but it says
needCleanup = 0 '\000'
which agrees with that.  Also the core dump appears to be because
currentEventTriggerState is NULL (please check that), which is
expected if EventTriggerBeginCompleteQuery did nothing.  However, then
EventTriggerEndCompleteQuery should not have gotten called at all.

I suspect you could work around this with

boolisCompleteQuery = (context <= PROCESS_UTILITY_QUERY);
-   boolneedCleanup;
+   volatile bool   needCleanup;
boolcommandCollected = false;

If that fixes it, it's definitely a compiler bug.  That function does
not change needCleanup after the sigsetjmp call, so per POSIX it
should not have to label the variable volatile.  This is far from
being the first such bug we've seen though.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] initdb failure on Debian sid/mips64el in EventTriggerEndCompleteQuery

[Christoph Berg]

Re: To PostgreSQL Hackers 2017-08-13 
<20170813130127.g3tcyzzvuvlpz...@msg.df7cb.de>
> 10beta3 and 9.6.4 are both failing during initdb on mips64el on
> Debian/sid (unstable):
> 
> https://buildd.debian.org/status/fetch.php?pkg=postgresql-9.6=mips64el=9.6.4-1=1502374949=0
> https://buildd.debian.org/status/fetch.php?pkg=postgresql-10=mips64el=10%7Ebeta3-1=1502535836=0
> 
> All other architectures have succeeded, as well as the 9.6.4 build for
> Debian/stretch (stable) on mips64el. The difference might be the
> compiler version (6.3.0 vs 7.1.0).

Seems to be a gcc-7 problem affecting several packages on mips64el:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871514

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers