GiST on 64-bit box - Mailing list pgsql-hackers

From Teodor Sigaev
Subject GiST on 64-bit box
Date
Msg-id 3C63EE7F.3040302@stack.net
Whole thread Raw
Responses Re: GiST on 64-bit box
List pgsql-hackers
Hello,

We have report that all GiST opclasses cause a coredump while creating index on 
64-bit Solaris. I try to make installcheck GiST's contrib modules on DEC Alpha 
and got the same result. So it may be one problem.

Compiler:
gcc -v
Reading specs from 
/usr/local/egcs/lib/gcc-lib/alphaev56-dec-osf4.0c/egcs-2.90.23/specs
gcc version egcs-2.90.23 980102 (egcs-1.0.1 release)


Backtrace:
#0  0x12003d564 in gistdentryinit (giststate=0x11fffd820, nkey=0, e=0x1401b25a4, 
k=5370611216, r=0x140171ce8,    pg=0x1401ce620 "", o=1, b=8, l=0 '\000', isNull=0 '\000') at gist.c:1754
#1  0x12003b3b0 in gistSplit (r=0x140171ce8, buffer=-1, itup=0x140196a10, 
len=0x11fffd598, giststate=0x11fffd820,    res=0x0) at gist.c:1264
#2  0x120037be4 in gistlayerinsert (r=0x140171ce8, blkno=1075407376, 
itup=0x11fffd610, len=0x11fffd618, res=0x0,    giststate=0x11fffd820) at gist.c:515
#3  0x1200376d8 in gistdoinsert (r=0x140171ce8, itup=0x140196718, res=0x0, 
giststate=0x11fffd820) at gist.c:426
#4  0x120037228 in gistbuildCallback (index=0x140171ce8, htup=0x140196590, 
attdata=0x11fffd710,    nulls=0x11fffd790 " о\017@\001", tupleIsAlive=-24 'Х', state=0x1401ce620) 
at gist.c:275
#5  0x12008c4c4 in IndexBuildHeapScan (heapRelation=0x1, 
indexRelation=0x140171ce8, indexInfo=0x140196238,    callback=0x120037020 <gistbuildCallback>,
callback_state=0x11fffd820)at 
 
index.c:1805
#6  0x120036f70 in gistbuild (fcinfo=0x11fffd820) at gist.c:186
#7  0x1201df8c4 in OidFunctionCall3 (functionId=536860704, arg1=5370215808, 
arg2=5370223848, arg3=5370372664)    at fmgr.c:1190
...

Output to sdterr:
Unaligned access pid=6018 <postgres> va=0x1401b25a4 pc=0x12003d560 
ra=0x12003b3b0 inst=0xb6690000

Source (gist.c, around 1264 line):        /* generate the item array */        entryvec = (bytea *) palloc(VARHDRSZ +
(*len+ 1) * sizeof(GISTENTRY));        decompvec = (bool *) palloc(VARHDRSZ + (*len + 1) * sizeof(bool));
VARATT_SIZEP(entryvec)= (*len + 1) * sizeof(GISTENTRY) + VARHDRSZ;        for (i = 1; i <= *len; i++)        {
     datum = index_getattr(itup[i - 1], 1, giststate->tupdesc, &IsNull);                gistdentryinit(giststate, 0,
&((GISTENTRY*) VARDATA(entryvec))[i],                                           datum, r, p, i,
ATTSIZE(datum,giststate->tupdesc, 1, IsNull), FALSE, IsNull);                if ((!isAttByVal(giststate, 0)) &&
((GISTENTRY*) 
 
VARDATA(entryvec))[i].key != datum)                        decompvec[i] = TRUE;                else
  decompvec[i] = FALSE;        }
 

Core dump causes on first call gistdentryinit, because pointer
&((GISTENTRY *) VARDATA(entryvec))[1] has not 8-byte aligment. Difference 
between entryvec and this pointer is equal 44 bytes.

Can  you give some advice how make aligment? or, may be exist another way for 
solving...

BTW, on HPUX 11.0 all works fine.

Thank you.


-- 
Teodor Sigaev
teodor@stack.net




pgsql-hackers by date:

Previous
From: Matthew Kirkwood
Date:
Subject: Re: Why dump/restore to upgrade?
Next
From: Tom Lane
Date:
Subject: Re: 7.2 - changed array_out() - quotes vs no quotes