Thread: 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 removedat 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
Re: Buildfarm member gypsy_moth seems not to like alignment patch
From
Jorgen Austvik - Sun Norway
Date:
> 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
Attachment
Re: Buildfarm member gypsy_moth seems not to like alignment patch
From
Jorgen Austvik - Sun Norway
Date:
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 removedat 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? 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" [3] heap_insert(relation = 0xcd8ff8, tup = 0xdba3e8, cid = 10U, use_wal = '\001', use_fsm = '\001'), line 1815 in "heapam.c" [4] simple_heap_insert(relation = 0xcd8ff8, tup = 0xdba3e8), line 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" [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" [7] DefineViewRules(viewOid = 10950U, viewParse = 0xdab070, replace = '\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" [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" [10] PortalRunUtility(portal = 0xd39e68, utilityStmt = 0xd3f920, 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" [12] PortalRun(portal = 0xd39e68, count = 2147483647, isTopLevel = '\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" [14] PostgresMain(argc = 9, argv = 0xc3c364, username = 0xc3a380 "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
Attachment
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