Re: SIGSEGV taken on 8.1 during dump/reload

Поиск
Список
Период
Сортировка
От Teodor Sigaev
Тема Re: SIGSEGV taken on 8.1 during dump/reload
Дата
Msg-id 4370966C.4050705@sigaev.ru
обсуждение исходный текст
Ответ на Re: SIGSEGV taken on 8.1 during dump/reload  (Robert Creager <Robert_Creager@LogicalChaos.org>)
Ответы Re: SIGSEGV taken on 8.1 during dump/reload  (Robert Creager <Robert_Creager@LogicalChaos.org>)
Список pgsql-hackers
Hmm, did you recompile pg_sphere module for 8.1?

Robert Creager wrote:
> When grilled further on (Mon, 7 Nov 2005 22:25:17 -0700),
> Robert Creager <Robert_Creager@LogicalChaos.org> confessed:
> 
> Sorry, I'll just trickle out the information.
> 
> tassiv=# \d catalog_ra_decl_index 
> Index "public.catalog_ra_decl_index"
>  Column |   Type    
> --------+-----------
>  loc    | spherekey
> gist, for table "public.catalog"
> 
> v->spl_right is address 0xbp - uninitialized?
> 
> (gdb) print *v
> $2 = {spl_left = 0x83e1308, spl_nleft = 8, spl_ldatum = 138286880, spl_lattr = {3930298096, 3929693296, 1075344513,
3928483696,3927878896, 50331648, 1076099872, 1076099872, 1076100640, 1076099944, 1076099872, 0, 0, 0, 1, 1076099872,
46088,24, 138269392, 108, 8205, 1076099872, 1076097560, 1077018624, 1223005861, 2281761506, 1072462523, 8192,
1076979200,1348122942, 3218058668, 3588489616}, spl_lattrsize = {1072628007, 1223130252, 0, -1073754968, 1223107331,
-1073755008,1196715552, 4033364, 1076979200, 8132, 32, 138269400, 58657919, 717016950, 1071875034, 1883413536,
-1077677968,-817345387, 1072225709, 138175768, 138175768, 1223130252, 1223130252, -1073754936, 1223083881, 138269472,
1196715552,138269472, 138269428, -1073754256, -1073754256, -1073754376}, spl_lisnull =
"ÍD#\bàÌÿ¿\000\000\000\000(Íÿ¿\2004;\b×ÿ¿\000\000\000\000\000\000\000", spl_leftvalid = 20 '\024', spl_right = 0xdb,
spl_nright= 138286924, spl_rdatum = 11, spl_rattr = {3463747944, 3883728496,0, 3882518896, 3881914096, 1, 3221212568,
138097456,138251092, 3878890096, 0, 0, 1222988060, 1222974760, 1222960776, 138097456, 3, 1075321604, 0, 1073825468,
1076097560,3221212576, 3221212540, 1075326465, 3221212576, 909216680, 825503793, 0, 138251202, 1076097560, 136751593,
3221212860},spl_rattrsize = {-1073754484, 1075303286, -1073754720, 136751593, -1073754428, 138251176, 0, -1073754560,
136027536,1196670896, 138269580, 32, 1196670856, 138251176, 138251194, 138251202, 226, 138251008, 0, 0, 0, 7904, 1024,
138269400,138269700, 138269688, 908, -1073754600, 136599995, 138175768, 138269700, 908}, spl_risnull =
"\030e<\b\000¼SG\001\000\000\000XÎÿ¿¤Îÿ¿\001\000\000\000Ñÿ¿\004Ô=\b", spl_rightvalid = 108 'l', spl_idgrp = 0x83dd78c,
spl_ngrp= 0x83dd378, spl_grpflag = 0x4 <Address 0x4 out of bounds>}
 
> 
> 
>>When grilled further on (Mon, 7 Nov 2005 08:07:14 -0700),
>>Robert Creager <Robert_Creager@logicalchaos.org> confessed:
>>
>>I'm currently attached to the dead (dying) process.  spl_nright seems pretty large...
>>
>>(gdb) print v->spl_nright
>>$3 = 138311580
>>
>>Program received signal SIGSEGV, Segmentation fault.
>>0x08082057 in gistUserPicksplit (r=0x48f3f1e4, entryvec=0x83e534c, v=0xbfffcbc0, itup=0x83e3454, len=227,
giststate=0xbfffd120)at gistutil.c:833
 
>>833             if (v->spl_right[v->spl_nright - 1] == InvalidOffsetNumber)
>>(gdb) bt
>>#0  0x08082057 in gistUserPicksplit (r=0x48f3f1e4, entryvec=0x83e534c, v=0xbfffcbc0, itup=0x83e3454, len=227,
giststate=0xbfffd120)at gistutil.c:833
 
>>#1  0x0807f249 in gistSplit (r=0x48f3f1e4, buffer=8917, itup=0x83e3454, len=0xbfffcea4, dist=0xbfffcea0,
giststate=0xbfffd120)at gist.c:1083
 
>>#2  0x0807c8ab in gistplacetopage (state=0xbfffcf10, giststate=0xbfffd120) at gist.c:331
>>#3  0x0807e2cd in gistmakedeal (state=0xbfffcf10, giststate=0xbfffd120) at gist.c:878
>>#4  0x0807c7e1 in gistdoinsert (r=0x48f3f1e4, itup=0x83e339c, giststate=0xbfffd120) at gist.c:299
>>#5  0x0807c5a6 in gistbuildCallback (index=0x48f3f1e4, htup=0x83c3de8, values=0xbfffd020, isnull=0xbfffd000 "",
tupleIsAlive=1'\001', state=0xbfffd120)
 
>>    at gist.c:207
>>#6  0x080cbb14 in IndexBuildHeapScan (heapRelation=0x48f3e1cc, indexRelation=0x48f3f1e4, indexInfo=0x83c3b6c,
callback=0x807c4f0<gistbuildCallback>, 
 
>>    callback_state=0xbfffd120) at index.c:1573
>>#7  0x0807c3b5 in gistbuild (fcinfo=0xbfffe670) at gist.c:145
>>#8  0x08234dfd in OidFunctionCall3 (functionId=782, arg1=1223942604, arg2=1223946724, arg3=138165100) at fmgr.c:1460
>>#9  0x080cb8d3 in index_build (heapRelation=0x48f3e1cc, indexRelation=0x48f3f1e4, indexInfo=0x83c3b6c) at
index.c:1353
>>#10 0x080cacdc in index_create (heapRelationId=128249, indexRelationName=0x83a0b94 "catalog_ra_decl_index",
indexRelationId=128443,indexInfo=0x83c3b6c, 
 
>>    accessMethodObjectId=783, tableSpaceId=0, classObjectId=0x83c9cfc, primary=0 '\0', isconstraint=0 '\0',
allow_system_table_mods=0'\0', 
 
>>    skip_build=0 '\0') at index.c:757
>>#11 0x08110671 in DefineIndex (heapRelation=0x30f, indexRelationName=0x83a0b94 "catalog_ra_decl_index",
indexRelationId=0,
 
>>    accessMethodName=0x83a0c00 "gist", tableSpaceName=0x0, attributeList=0x83a0c58, predicate=0x0, rangetable=0x0,
unique=0'\0', primary=0 '\0', 
 
>>    isconstraint=0 '\0', is_alter_table=0 '\0', check_rights=1 '\001', skip_build=0 '\0', quiet=0 '\0') at
indexcmds.c:383
>>#12 0x081c409b in ProcessUtility (parsetree=0x83a0c74, params=0x0, dest=0x83a0cf0, completionTag=0xbfffec00 "") at
utility.c:748
>>#13 0x081c2b84 in PortalRunUtility (portal=0x83aad14, query=0x83a0a7c, dest=0x83a0cf0, completionTag=0xbfffec00 "")
atpquery.c:987
 
>>#14 0x081c2e0b in PortalRunMulti (portal=0x83aad14, dest=0x83a0cf0, altdest=0x83a0cf0, completionTag=0xbfffec00 "")
atpquery.c:1054
 
>>#15 0x081c26a6 in PortalRun (portal=0x83aad14, count=2147483647, dest=0x83a0cf0, altdest=0x83a0cf0,
completionTag=0xbfffec00"") at pquery.c:665
 
>>#16 0x081be579 in exec_simple_query (query_string=0x83a0864 "CREATE INDEX catalog_ra_decl_index ON catalog USING gist
(loc);")at postgres.c:1014
 
>>#17 0x081c1377 in PostgresMain (argc=4, argv=0x8345f3c, username=0x8345f14 "robert") at postgres.c:3168
>>#18 0x08198692 in BackendRun (port=0x835ea08) at postmaster.c:2854
>>#19 0x081980a5 in BackendStartup (port=0x835ea08) at postmaster.c:2498
>>#20 0x081963fe in ServerLoop () at postmaster.c:1231
>>#21 0x081957aa in PostmasterMain (argc=3, argv=0x8344788) at postmaster.c:943
>>#22 0x08158b49 in main (argc=3, argv=0x8344788) at main.c:256
>>
>>-- 
>> 22:06:46 up 36 days, 14:41,  7 users,  load average: 2.22, 2.55, 3.26
>>Linux 2.6.5-02 #8 SMP Mon Jul 12 21:34:44 MDT 2004
> 
> 
> 

-- 
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
  WWW: http://www.sigaev.ru/
 


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Csaba Nagy
Дата:
Сообщение: Re: parameterized limit statements
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Is there any other way to compile pgsql without gmake