GiST on 64-bit box

Поиск
Список
Период
Сортировка
От Teodor Sigaev
Тема GiST on 64-bit box
Дата
Msg-id 3C63EE7F.3040302@stack.net
обсуждение исходный текст
Ответы Re: GiST on 64-bit box  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Matthew Kirkwood
Дата:
Сообщение: Re: Why dump/restore to upgrade?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: 7.2 - changed array_out() - quotes vs no quotes