segfault at aset.c:539 - Mailing list pgsql-bugs
From | Tomas Szepe |
---|---|
Subject | segfault at aset.c:539 |
Date | |
Msg-id | 20030710095414.GL16513@louise.pinerecords.com Whole thread Raw |
List | pgsql-bugs |
Hi list, I'm getting an ugly non-deterministic segfault in postmaster at aset.c:539, likely on account of a NULL pointer dereference. /* * Request is small enough to be treated as a chunk. Look in the * corresponding free list to see if there is a free chunk we could * reuse. */ fidx = AllocSetFreeIndex(size); priorfree = NULL; for (chunk = set->freelist[fidx]; chunk; chunk = (AllocChunk) chunk->aset) { if (chunk->size >= size) /* <--- line 539 */ break; priorfree = chunk; } bt: #0 0x081e2803 in AllocSetAlloc (context=0x82c6300, size=32) at aset.c:539 #1 0x081e32d4 in MemoryContextAlloc (context=0x82c6300, size=32) at mcxt.c:452 #2 0x0808b02c in btrescan (fcinfo=0xbfffe4f0) at nbtree.c:417 #3 0x081d89e4 in OidFunctionCall2 (functionId=334, arg1=137435560, arg2=3221219328) at fmgr.c:1248 #4 0x08085acd in index_rescan (scan=0x83119a8, key=0xbfffe800) at indexam.c:314 #5 0x080855c3 in RelationGetIndexScan (indexRelation=0x82d5670, nkeys=1, key=0xbfffe800) at genam.c:118 #6 0x0808af61 in btbeginscan (fcinfo=0xbfffe670) at nbtree.c:392 #7 0x081d8b1b in OidFunctionCall3 (functionId=333, arg1=137188976, arg2=1, arg3=3221219328) at fmgr.c:1275 #8 0x080859e5 in index_beginscan (heapRelation=0x82c6b98, indexRelation=0x82d5670, snapshot=0x0, nkeys=1, key=0xbfffe800) at indexam.c:268 #9 0x080856cd in systable_beginscan (heapRelation=0x82c6b98, indexRelname=0x8260a3f "pg_proc_oid_index", indexOK=1 '\001', snapshot=0x0, nkeys=1, key=0xbfffe800) at genam.c:219 #10 0x081cb8f5 in SearchCatCache (cache=0x406da088, v1=2034, v2=0, v3=0, v4=0) at catcache.c:1193 #11 0x081d28e8 in SearchSysCache (cacheId=25, key1=2034, key2=0, key3=0, key4=0) at syscache.c:536 #12 0x080ad193 in pg_proc_aclcheck (proc_oid=2034, userid=100, mode=128) at aclchk.c:1072 #13 0x081d49d2 in init_fcache (foid=2034, nargs=1, fcacheCxt=0x82c6278) at fcache.c:33 #14 0x08103021 in ExecEvalFunc (funcClause=0x8301700, econtext=0x830dc18, isNull=0xbfffeaa0 "", isDone=0xbfffe990) at execQual.c:1162 #15 0x08103c21 in ExecEvalExpr (expression=0x8301700, econtext=0x830dc18, isNull=0xbfffeaa0 "", isDone=0xbfffe990) at execQual.c:1715 #16 0x08102597 in ExecEvalFuncArgs (fcinfo=0xbfffea10, argList=0x8301728, econtext=0x830dc18) at execQual.c:624 #17 0x081026ca in ExecMakeFunctionResult (fcache=0x8310508, arguments=0x8301728, econtext=0x830dc18, isNull=0xbfffec60 "", isDone=0xbfffeb50) at execQual.c:680 #18 0x08103054 in ExecEvalFunc (funcClause=0x8301740, econtext=0x830dc18, isNull=0xbfffec60 "", isDone=0xbfffeb50) at execQual.c:1167 #19 0x08103c21 in ExecEvalExpr (expression=0x8301740, econtext=0x830dc18, isNull=0xbfffec60 "", isDone=0xbfffeb50) at execQual.c:1715 #20 0x08102597 in ExecEvalFuncArgs (fcinfo=0xbfffebd0, argList=0x8301768, econtext=0x830dc18) at execQual.c:624 #21 0x081026ca in ExecMakeFunctionResult (fcache=0x8310400, arguments=0x8301768, econtext=0x830dc18, isNull=0xbfffee20 "", isDone=0xbfffed10) at execQual.c:680 #22 0x08103054 in ExecEvalFunc (funcClause=0x8301780, econtext=0x830dc18, isNull=0xbfffee20 "", isDone=0xbfffed10) at execQual.c:1167 #23 0x08103c21 in ExecEvalExpr (expression=0x8301780, econtext=0x830dc18, isNull=0xbfffee20 "", isDone=0xbfffed10) at execQual.c:1715 #24 0x08102597 in ExecEvalFuncArgs (fcinfo=0xbfffed90, argList=0x8301b00, econtext=0x830dc18) at execQual.c:624 #25 0x081026ca in ExecMakeFunctionResult (fcache=0x83102f8, arguments=0x8301b00, econtext=0x830dc18, isNull=0xbfffef33 "", isDone=0x0) at execQual.c:680 #26 0x08102fcf in ExecEvalOper (opClause=0x8301b18, econtext=0x830dc18, isNull=0xbfffef33 "", isDone=0x0) at execQual.c:1125 #27 0x08103bf9 in ExecEvalExpr (expression=0x8301b18, econtext=0x830dc18, isNull=0xbfffef33 "", isDone=0x0) at execQual.c:1711 #28 0x081032a1 in ExecEvalOr (orExpr=0x8301f18, econtext=0x830dc18, isNull=0xbfffef33 "") at execQual.c:1316 #29 0x08103c42 in ExecEvalExpr (expression=0x8301f18, econtext=0x830dc18, isNull=0xbfffef33 "", isDone=0x0) at execQual.c:1719 #30 0x08103ec8 in ExecQual (qual=0x8302ad0, econtext=0x830dc18, resultForNull=0 '\0') at execQual.c:1885 #31 0x08104619 in ExecScan (node=0x83028e8, accessMtd=0x810cd64 <SeqNext>) at execScan.c:124 #32 0x0810ce8e in ExecSeqScan (node=0x83028e8) at nodeSeqscan.c:133 #33 0x08100e4d in ExecProcNode (node=0x83028e8, parent=0x830d988) at execProcnode.c:291 #34 0x0810db29 in ExecSort (node=0x830d988) at nodeSort.c:162 #35 0x08100f0b in ExecProcNode (node=0x830d988, parent=0x0) at execProcnode.c:337 #36 0x080ff6ba in ExecutePlan (estate=0x830da38, plan=0x830d988, operation=CMD_SELECT, numberTuples=0, direction=ForwardScanDirection, destfunc=0x830dfe0) at execMain.c:958 #37 0x080fea01 in ExecutorRun (queryDesc=0x830da10, estate=0x830da38, direction=ForwardScanDirection, count=0) at execMain.c:195 #38 0x0816fa5a in ProcessQuery (parsetree=0x82fcbb8, plan=0x830d988, dest=Remote, completionTag=0xbffff1b0 "") at pquery.c:242 #39 0x0816db96 in pg_exec_query_string (query_string=0x82fbcb8, dest=Remote, parse_context=0x82c6168) at postgres.c:838 #40 0x0816eecc in PostgresMain (argc=4, argv=0xbffff470, username=0x82c1741 "kala") at postgres.c:2013 #41 0x0814c34e in DoBackend (port=0x82c1610) at postmaster.c:2310 #42 0x0814ba06 in BackendStartup (port=0x82c1610) at postmaster.c:1932 #43 0x0814a6ba in ServerLoop () at postmaster.c:1009 #44 0x0814a1b5 in PostmasterMain (argc=2, argv=0x82a8ae8) at postmaster.c:788 #45 0x08119fe4 in main (argc=2, argv=0xbffffe04) at main.c:210 #46 0x40209757 in __libc_start_main () from /lib/libc.so.6 0x81e27fc <AllocSetAlloc+270>: jne 0x81e2800 <AllocSetAlloc+274> 0x81e27fe <AllocSetAlloc+272>: jmp 0x81e281d <AllocSetAlloc+303> 0x81e2800 <AllocSetAlloc+274>: mov 0xfffffff4(%ebp),%eax 0x81e2803 <AllocSetAlloc+277>: mov 0x4(%eax),%eax 0x81e2806 <AllocSetAlloc+280>: cmp 0xc(%ebp),%eax 0x81e2809 <AllocSetAlloc+283>: jb 0x81e280d <AllocSetAlloc+287> 0x81e280b <AllocSetAlloc+285>: jmp 0x81e281d <AllocSetAlloc+303> Sometimes postmaster doesn't die but prints the following error message instead (the chunk# varies): ERROR: AllocSetFree: cannot find block containing chunk 0x8337444 Test case: init the db for LATIN2, createdb -E LATIN2 testdb (that's how I'm running; can't say if the oops happens for C too), then "psql -f <file_attached_to_this_post> testdb" -- you may need to run the command a couple dozen times before your postmaster blows up. The SIGSEGV strikes at the SELECT. Anyone with a fix? :) -- Tomas Szepe <szepe@pinerecords.com>
Attachment
pgsql-bugs by date: