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

2017-09-04 Thread 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

2017-08-22 Thread 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

2017-08-13 Thread 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

2017-08-13 Thread 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

2017-08-13 Thread 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

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

2017-08-13 Thread Christoph Berg 
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).

Command was: "initdb" -D 
"/home/myon/postgresql-9.6/postgresql-9.6-9.6.3/build/src/t
est/regress/./tmp_check/data" --noclean --nosync > 
"/home/myon/postgresql-9.6/postgr
esql-9.6-9.6.3/build/src/test/regress/log/initdb.log" 2>&1

 build/src/test/regress/log/initdb.log 
Running in noclean mode.  Mistakes will not be cleaned up.
The files belonging to this database system will be owned by user "myon".
This user must also own the server process.

The database cluster will be initialized with locales
  COLLATE:  de_DE.utf8
  CTYPE:de_DE.utf8
  MESSAGES: C
  MONETARY: de_DE.utf8
  NUMERIC:  de_DE.utf8
  TIME: de_DE.utf8
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "german".

Data page checksums are disabled.

creating directory 
/home/myon/postgresql-9.6/postgresql-9.6-9.6.3/build/src/test/regress/./tmp_check/data
 ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting dynamic shared memory implementation ... posix
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... Segmentation fault (core dumped)
child process exited with exit code 139


$ gdb build/tmp_install/usr/lib/postgresql/9.6/bin/postgres 
build/src/test/regress/tmp_check/data/core 
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "mips64el-linux-gnuabi64".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from 
build/tmp_install/usr/lib/postgresql/9.6/bin/postgres...done.
[New LWP 24217]
[Thread debugging using libthread_db enabled]
Using host libthread_db library 
"/lib/mips64el-linux-gnuabi64/libthread_db.so.1".
Core was generated by 
`/home/myon/postgresql-9.6/postgresql-9.6-9.6.3/build/tmp_install/usr/lib/postgr'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00aababa6634 in EventTriggerEndCompleteQuery ()
at ./build/../src/backend/commands/event_trigger.c:1263
1263MemoryContextDelete(currentEventTriggerState->cxt);
(gdb) bt full
#0  0x00aababa6634 in EventTriggerEndCompleteQuery ()
at ./build/../src/backend/commands/event_trigger.c:1263
prevstate = 
#1  0x00aabad6d508 in ProcessUtilitySlow (
parsetree=parsetree@entry=0xaac3688428, 
queryString=queryString@entry=0xaac3687888 "REVOKE ALL on pg_authid FROM 
public;\n", context=context@entry=PROCESS_UTILITY_TOPLEVEL, 
params=params@entry=0x0, 
completionTag=completionTag@entry=0x985218 "", 
dest=0xaabb0a0378 ) at 
./build/../src/backend/tcop/utility.c:1582
isTopLevel = 1 '\001'
isCompleteQuery = 1 '\001'
needCleanup = 0 '\000'
commandCollected = 
address = {classId = 2, objectId = 0, objectSubId = 0}
secondaryObject = {classId = 0, objectId = 0, objectSubId = 0}
#2  0x00aabad6c6cc in standard_ProcessUtility (parsetree=0xaac3688428, 
queryString=0xaac3687888 "REVOKE ALL on pg_authid FROM public;\n", 
context=, params=0x0, dest=0xaabb0a0378 , 
completionTag=0x985218 "") at ./build/../src/backend/tcop/utility.c:907
isTopLevel = 1 '\001'
__func__ = "standard_ProcessUtility"
#3  0x00aabad6d33c in ProcessUtility (parsetree=, 
queryString=, context=, params=, 
dest=, completionTag=)
at ./build/../src/backend/tcop/utility.c:336
No locals.
#4  0x00aabad68e80 in PortalRunUtility (portal=portal@entry=0xaac368a8a8, 
utilityStmt=utilityStmt@entry=0xaac3688428, 
isTopLevel=isTopLevel@entry=1 '\001', 
setHoldSnapshot=setHoldSnapshot@entry=0 '\000', 
dest=0xaabb0a0378 , completionTag=0x985218 "")
at ./build/../src/backend/tcop/pquery.c:1193
snapshot = 0xaac368c8e8
__func__ = "PortalRunUtility"
#5  0x00aabad69d70 in PortalRunMulti (portal=portal@entry=0xaac368a8a8,