Buildfarm member gypsy_moth seems not to like alignment patch
It looks like gypsy_moth has been failing like this:
creating directory /export/home/tmp/pg-test/build-suncc/HEAD/pgsql.21325/src/test/regress/./tmp_check/data ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers/max_fsm_pages ... 32MB/204800
creating configuration files ... ok
creating template1 database in /export/home/tmp/pg-test/build-suncc/HEAD/pgsql.21325/src/test/regress/./tmp_check/data/base/1 ... ok
initializing pg_authid ... ok
initializing dependencies ... ok
creating system views ... Bus Error - core dumped
child process exited with exit code 138
initdb: data directory "/export/home/tmp/pg-test/build-suncc/HEAD/pgsql.21325/src/test/regress/./tmp_check/data" not removed at user's request
since I put in this patch:
http://archives.postgresql.org/pgsql-committers/2008-02/msg00270.php
This is unfortunate and surprising, since that patch was intended to
prevent compilers from making unsafe alignment assumptions, but it sure
looks like this compiler has instead added a new one. Could you poke
into it --- at least get a stack trace from the core dump?
regards, tom lane
Tom Lane wrote:
It looks like gypsy_moth has been failing like this:
creating directory /export/home/tmp/pg-test/build-suncc/HEAD/pgsql.21325/src/test/regress/./tmp_check/data ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers/max_fsm_pages ... 32MB/204800
creating configuration files ... ok
creating template1 database in /export/home/tmp/pg-test/build-suncc/HEAD/pgsql.21325/src/test/regress/./tmp_check/data/base/1 ... ok
initializing pg_authid ... ok
initializing dependencies ... ok
creating system views ... Bus Error - core dumped
child process exited with exit code 138
initdb: data directory "/export/home/tmp/pg-test/build-suncc/HEAD/pgsql.21325/src/test/regress/./tmp_check/data" not removed at user's requestsince I put in this patch:
http://archives.postgresql.org/pgsql-committers/2008-02/msg00270.phpThis is unfortunate and surprising, since that patch was intended to
prevent compilers from making unsafe alignment assumptions, but it sure
looks like this compiler has instead added a new one. Could you poke
into it --- at least get a stack trace from the core dump?
Running initdb with debug:
------8<------------8<------------8<------------8<------------8<------------8<------
$./initdb -D /export/home/tmp/test -d -n
<snip>
DEBUG: name: unnamed; blockState: STARTED; state: INPROGR,
xid/subid/cid: 0/1/35, nestlvl: 1, children: <>
DEBUG: commit transaction
DEBUG: proc_exit(0)
DEBUG: shmem_exit(0)
DEBUG: exit(0)
ok
initializing pg_authid ... ok
initializing dependencies ... ok
creating system views ... Bus Error - core dumped
child process exited with exit code 138
initdb: data directory "/export/home/tmp/test" not removed at user's request
------8<------------8<------------8<------------8<------------8<------------8<------
Stack trace:
------8<------------8<------------8<------------8<------------8<------------8<------
$ /opt/SUNWspro8/bin/dbx long_path/postgres core
program terminated by signal BUS (invalid address alignment)
Current function is toast_save_datum
1171 SET_VARSIZE(&chunk_data, chunk_size + VARHDRSZ);
(dbx) where
=>[1] toast_save_datum(rel = 0xcd8ff8, value = 14406480U, use_wal =
\001', use_fsm = '\001'), line 1171 in "tuptoaster.c"
[2]: toast_insert_or_update(rel = 0xcd8ff8, newtup = 0xdba3e8, oldtup = (nil), use_wal = '\001', use_fsm = '\001'), line 700 in "tuptoaster.c"
= (nil), use_wal = '\001', use_fsm = '\001'), line 700 in "tuptoaster.c"
[3]: heap_insert(relation = 0xcd8ff8, tup = 0xdba3e8, cid = 10U, use_wal = '\001', use_fsm = '\001'), line 1815 in "heapam.c"
use_wal = '\001', use_fsm = '\001'), line 1815 in "heapam.c"
[4]: simple_heap_insert(relation = 0xcd8ff8, tup = 0xdba3e8), line 1937 in "heapam.c"
1937 in "heapam.c"
[5]: InsertRule(rulname = 0xdaf730 "_RETURN", evtype = 1, eventrel_oid = 10950U, evslot_index = -1, evinstead = '\001', event_qual = (nil), action = 0xdaf760, replace = '\0'), line 134 in "rewriteDefine.c"
= 10950U, evslot_index = -1, evinstead = '\001', event_qual = (nil),
action = 0xdaf760, replace = '\0'), line 134 in "rewriteDefine.c"
[6]: DefineQueryRewrite(rulename = 0xdaf730 "_RETURN", event_relid = 10950U, event_qual = (nil), event_type = CMD_SELECT, is_instead = '\001', replace = '\0', action = 0xdaf760), line 461 in "rewriteDefine.c"
10950U, event_qual = (nil), event_type = CMD_SELECT, is_instead =
'\001', replace = '\0', action = 0xdaf760), line 461 in "rewriteDefine.c"
[7]: DefineViewRules(viewOid = 10950U, viewParse = 0xdab070, replace = '\0'), line 275 in "view.c"
'\0'), line 275 in "view.c"
[8]: DefineView(stmt = 0xd3f920, queryString = 0xd9b888 "/*\n * PostgreSQL System Views\n *\n * Copyright (c) 1996-2008, PostgreSQL Global Development Group\n *\n * $PostgreSQL: pgsql/src/backend/catalog/system_views.sql,v 1.47 2007/10/22 20:13:37 tgl Exp $\n */\n\nCREATE VIEW pg_roles AS \n SELECT \n rolname,\n rolsuper,\n rolinherit,\n rolcreaterole,\n rolcreatedb,\n rolcatupdate,\n rolcanlogin,\n rolconnlimit,\n '********'::text as rolpassword,\n rolvaliduntil,\n rolconfig,\n oid\n FROM pg_aut" ...), line 447 in "view.c"
PostgreSQL System Views\n *\n * Copyright (c) 1996-2008, PostgreSQL
Global Development Group\n *\n * $PostgreSQL:
pgsql/src/backend/catalog/system_views.sql,v 1.47 2007/10/22 20:13:37
tgl Exp $\n */\n\nCREATE VIEW pg_roles AS \n SELECT \n
rolname,\n rolsuper,\n rolinherit,\n
rolcreaterole,\n rolcreatedb,\n rolcatupdate,\n
rolcanlogin,\n rolconnlimit,\n '********'::text as
rolpassword,\n rolvaliduntil,\n rolconfig,\n oid\n
FROM pg_aut" ...), line 447 in "view.c"
[9]: ProcessUtility(parsetree = 0xd3f920, queryString = 0xd9b888 "/*\n * PostgreSQL System Views\n *\n * Copyright (c) 1996-2008, PostgreSQL Global Development Group\n *\n * $PostgreSQL: pgsql/src/backend/catalog/system_views.sql,v 1.47 2007/10/22 20:13:37 tgl Exp $\n */\n\nCREATE VIEW pg_roles AS \n SELECT \n rolname,\n rolsuper,\n rolinherit,\n rolcreaterole,\n rolcreatedb,\n rolcatupdate,\n rolcanlogin,\n rolconnlimit,\n '********'::text as rolpassword,\n rolvaliduntil,\n rolconfig,\n oid\n FROM pg_aut" ..., params = (nil), isTopLevel = '\0', dest = 0xbb1534, completionTag = 0xffbef64c ""), line 894 in "utility.c"
* PostgreSQL System Views\n *\n * Copyright (c) 1996-2008, PostgreSQL
Global Development Group\n *\n * $PostgreSQL:
pgsql/src/backend/catalog/system_views.sql,v 1.47 2007/10/22 20:13:37
tgl Exp $\n */\n\nCREATE VIEW pg_roles AS \n SELECT \n
rolname,\n rolsuper,\n rolinherit,\n
rolcreaterole,\n rolcreatedb,\n rolcatupdate,\n
rolcanlogin,\n rolconnlimit,\n '********'::text as
rolpassword,\n rolvaliduntil,\n rolconfig,\n oid\n
FROM pg_aut" ..., params = (nil), isTopLevel = '\0', dest =
0xbb1534, completionTag = 0xffbef64c ""), line 894 in "utility.c"
[10]: PortalRunUtility(portal = 0xd39e68, utilityStmt = 0xd3f920, isTopLevel = '\0', dest = 0xbb1534, completionTag = 0xffbef64c ""), line 1178 in "pquery.c"
isTopLevel = '\0', dest = 0xbb1534, completionTag = 0xffbef64c ""), line
1178 in "pquery.c"
[11]: PortalRunMulti(portal = 0xd39e68, isTopLevel = '\0', dest = 0xbb1534, altdest = 0xbb1534, completionTag = 0xffbef64c ""), line 1266 in "pquery.c"
0xbb1534, altdest = 0xbb1534, completionTag = 0xffbef64c ""), line 1266
in "pquery.c"
[12]: PortalRun(portal = 0xd39e68, count = 2147483647, isTopLevel = '\0', dest = 0xbb1534, altdest = 0xbb1534, completionTag = 0xffbef64c ""), line 814 in "pquery.c"
'\0', dest = 0xbb1534, altdest = 0xbb1534, completionTag = 0xffbef64c
""), line 814 in "pquery.c"
[13]: exec_simple_query(query_string = 0xd2fe38 "/*\n * PostgreSQL System Views\n *\n * Copyright (c) 1996-2008, PostgreSQL Global Development Group\n *\n * $PostgreSQL: pgsql/src/backend/catalog/system_views.sql,v 1.47 2007/10/22 20:13:37 tgl Exp $\n */\n\nCREATE VIEW pg_roles AS \n SELECT \n rolname,\n rolsuper,\n rolinherit,\n rolcreaterole,\n rolcreatedb,\n rolcatupdate,\n rolcanlogin,\n rolconnlimit,\n '********'::text as rolpassword,\n rolvaliduntil,\n rolconfig,\n oid\n FROM pg_aut" ...), line 969 in "postgres.c"
System Views\n *\n * Copyright (c) 1996-2008, PostgreSQL Global
Development Group\n *\n * $PostgreSQL:
pgsql/src/backend/catalog/system_views.sql,v 1.47 2007/10/22 20:13:37
tgl Exp $\n */\n\nCREATE VIEW pg_roles AS \n SELECT \n
rolname,\n rolsuper,\n rolinherit,\n
rolcreaterole,\n rolcreatedb,\n rolcatupdate,\n
rolcanlogin,\n rolconnlimit,\n '********'::text as
rolpassword,\n rolvaliduntil,\n rolconfig,\n oid\n
FROM pg_aut" ...), line 969 in "postgres.c"
[14]: PostgresMain(argc = 9, argv = 0xc3c364, username = 0xc3a380 "autopg"), line 3531 in "postgres.c"
"autopg"), line 3531 in "postgres.c"
[15]: main(argc = 10, argv = 0xc3c360), line 186 in "main.c"
(dbx) print chunk_data
chunk_data = {
hdr = {
vl_len_ = ""
vl_dat = ""
}
data = ""
}
(dbx) print chunk_size
chunk_size = 1996
------8<------------8<------------8<------------8<------------8<------------8<------
If I can be to further assistance - please let me know.
-J
--
J�rgen Austvik, Software Engineering - QA
Sun Microsystems Database Technology Group
Tom Lane wrote:
This is unfortunate and surprising, since that patch was intended to
prevent compilers from making unsafe alignment assumptions, but it sure
looks like this compiler has instead added a new one. Could you poke
into it --- at least get a stack trace from the core dump?
Forgot some information about local variables:
(dbx) dump
toasttupDesc = 0xcf9538
chunk_size = 1996
t_values = ARRAY
toast_pointer = RECORD
chunk_seq = 1
rel = 0xcd8ff8
toastidx = 0xcf9858
toasttup = 0x8
toastrel = 0xcf9748
use_wal = '\001'
result = 0x1
data_p = 0xdbd354 ""
use_fsm = '\001'
data_todo = 2286
mycid = 10U
__func__ = "toast_save_datum"
t_isnull = ARRAY
value = 14406480U
chunk_data = RECORD
(dbx) print toast_pointer
toast_pointer = {
va_rawsize = 11963
va_extsize = 2286
va_valueid = 10953U
va_toastrelid = 2838U
}
(dbx) print t_values
t_values = (10953U, 0, 4290673827U)
(dbx) print t_isnull
t_isnull = ""
(dbx) print chunk_data
chunk_data = {
hdr = {
vl_len_ = ""
vl_dat = ""
}
data = ""
}
-J
--
J�rgen Austvik, Software Engineering - QA
Sun Microsystems Database Technology Group
Jorgen Austvik - Sun Norway <Jorgen.Austvik@Sun.COM> writes:
Tom Lane wrote:
This is unfortunate and surprising, since that patch was intended to
prevent compilers from making unsafe alignment assumptions, but it sure
looks like this compiler has instead added a new one. Could you poke
into it --- at least get a stack trace from the core dump?
Running initdb with debug:
Hah, I guess the problem is that the compiler decided it was okay to put
the local variable "chunk_data" at an unaligned address. Patched, but
we'll have to see whether any other places have similar issues.
Thanks for doing the gdb-work.
regards, tom lane