Re: continued segmentation fault

Bob wrote:
> Is there any reason can't update to a newer version. Like 8.x?

We plan on going to the latest 7.4 the first of October. The latest 8.x
is on the schedule, but there will be coding changes required and
extensive testing, so that's a bit further out.

> Geoffrey wrote:
>> We continue to have segmentation faults of the /usr/bin/postgres process
>> as I mentioned in an earlier thread. In all cases, the core file
>> always indicates a segmentation fault, but the backtraces don't seem to
>> consistently point to any particular problem. Then again, when you go
>> stomping around in memory where you don't belong, all bets are probably off.
>>
>> I'm wondering out loud (here) if anyone thinks it might have something
>> to do with the version we're on? 7.4.7. We are planning to upgrade to
>> 7.4.13 soon, but were hoping to address this existing issue first.
>>
>> It's a bit difficult debugging this issue as I must initiate gdb via the
>> client. I have yet to reproduce this problem in my test environment,
>> but then again, I'm running my single debugging client, whereas in the
>> production system, there could well be 150-200 clients running.
>>
>> I've attached the latest backtrace, in the event anyone sees anything
>> glaringly obvious, please slap me in the head...
>>
>> Thanks in advance.
>>
>> --
>> Until later, Geoffrey
>>
>> Those who would give up essential Liberty, to purchase a little
>> temporary Safety, deserve neither Liberty nor Safety.
>> - Benjamin Franklin
>>
>> --------------020607020903010406060907
>> Content-Type: text/plain; charset=utf-8
>> Content-Disposition: inline;
>> filename="bt1031"
>> X-Google-AttachSize: 5397
>>
>> Using host libthread_db library "/lib/tls/libthread_db.so.1".
>> Core was generated by `postgres: chuck sev [local] SELECT '.
>> Program terminated with signal 11, Segmentation fault.
>> #0 0x0815c973 in cmtreefree (cm=0x9925064, tree=0x0, level=2)
>> at regc_color.c:125
>> in regc_color.c
>> #0 0x0815c973 in cmtreefree (cm=0x9925064, tree=0x0, level=2)
>> at regc_color.c:125
>> #1 0x0815c9bc in cmtreefree (cm=0x9925064, tree=0x98a1528, level=1)
>> at regc_color.c:131
>> #2 0x0815c9bc in cmtreefree (cm=0x9925064, tree=0x9925144, level=0)
>> at regc_color.c:131
>> #3 0x0815c8f1 in freecm (cm=0x9925064) at regc_color.c:97
>> #4 0x0815b458 in rfree (re=0x800) at regcomp.c:2105
>> #5 0x08162825 in pg_regfree (re=0x9925064) at regfree.c:53
>> #6 0x081aa8ad in RE_compile_and_execute (text_re=0x9f171a0,
>> dat=0x800 <Address 0x800 out of bounds>, dat_len=170796744, cflags=11,
>> nmatch=0, pmatch=0x0) at regexp.c:212
>> #7 0x081aafd2 in texticregexne (fcinfo=0xfeffac80) at regexp.c:387
>> #8 0x08107634 in ExecMakeFunctionResult (fcache=0x9f54ff0,
>> econtext=0x9f548e8, isNull=0xfeffad9b "", isDone=0x0) at execQual.c:907
>> #9 0x081091a0 in ExecEvalExpr (expression=0x9f54ff0, econtext=0x9f548e8,
>> isNull=0x0, isDone=0x9925064) at execQual.c:2257
>> #10 0x08109dbb in ExecQual (qual=0x9f54b10, econtext=0x9f548e8,
>> resultForNull=0 '\0') at execQual.c:2859
>> #11 0x0810a1e1 in ExecScan (node=0x9f54860, accessMtd=0x8112150 <SeqNext>)
>> at execScan.c:129
>> #12 0x08112239 in ExecSeqScan (node=0x800) at nodeSeqscan.c:131
>> #13 0x081060d6 in ExecProcNode (node=0x9f54860) at execProcnode.c:306
>> #14 0x0810e13b in ExecHash (node=0x9f54730) at nodeHash.c:81
>> #15 0x081061b5 in ExecProcNode (node=0x9f54730) at execProcnode.c:364
>> #16 0x0810ec6c in ExecHashJoin (node=0x942bbc8) at nodeHashjoin.c:128
>> #17 0x08106167 in ExecProcNode (node=0x942bbc8) at execProcnode.c:337
>> #18 0x0810f03b in ExecHashJoinOuterGetTuple (node=0x800, hjstate=0x942b460)
>> at nodeHashjoin.c:510
>> #19 0x0810ea94 in ExecHashJoin (node=0x942b460) at nodeHashjoin.c:152
>> #20 0x08106167 in ExecProcNode (node=0x942b460) at execProcnode.c:337
>> #21 0x0810d288 in agg_fill_hash_table (aggstate=0x942b850) at nodeAgg.c:905
>> #22 0x0810cec7 in ExecAgg (node=0x942b850) at nodeAgg.c:654
>> #23 0x0810619b in ExecProcNode (node=0x942b850) at execProcnode.c:356
>> #24 0x08104a1d in ExecutePlan (estate=0x942b398, planstate=0x942b850,
>> operation=CMD_SELECT, numberTuples=10, direction=2048, dest=0x826d134)
>> at execMain.c:1100
>> #25 0x08103df8 in ExecutorRun (queryDesc=0x9f17848,
>> direction=ForwardScanDirection, count=2048) at execMain.c:249
>> #26 0x0817b07b in PortalRunSelect (portal=0x9439c98, forward=0 '\0', count=10,
>> dest=0x826d134) at pquery.c:590
>> #27 0x0817b6d3 in PortalRunFetch (portal=0x9439c98, fdirection=2048,
>> count=2048, dest=0x800) at pquery.c:961
>> #28 0x08117c67 in _SPI_cursor_operation (portal=0x9439c98, forward=1 '\001',
>> count=10, dest=0x826d134) at spi.c:1315
>> #29 0x081171eb in SPI_cursor_fetch (portal=0x800, forward=1 '\001', count=2048)
>> at spi.c:881
>> #30 0x00a0ca39 in exec_stmt_fors (estate=0xfeffb210, stmt=0x950b188)
>> at pl_exec.c:1391
>> #31 0x00a0c10e in exec_stmt (estate=0xfeffb210, stmt=0x950b188)
>> at pl_exec.c:963
>> #32 0x00a0c005 in exec_stmts (estate=0xfeffb210, stmts=0x96fc0d8)
>> at pl_exec.c:903
>> #33 0x00a0be15 in exec_stmt_block (estate=0xfeffb210, block=0x944ba68)
>> at pl_exec.c:859
>> #34 0x00a0b061 in plpgsql_exec_function (func=0x96069c8, fcinfo=0xfeffb2f0)
>> at pl_exec.c:325
>> #35 0x00a07ff4 in plpgsql_call_handler (fcinfo=0xfeffb2f0) at pl_handler.c:124
>> #36 0x08107634 in ExecMakeFunctionResult (fcache=0x9f689a0,
>> econtext=0x9f68928, isNull=0xfeffb41b "", isDone=0x9f68c30)
>> at execQual.c:907
>> #37 0x0810918a in ExecEvalExpr (expression=0x9f689a0, econtext=0x9f68928,
>> isNull=0x0, isDone=0x9925064) at execQual.c:2253
>> #38 0x08109ec4 in ExecTargetList (targetlist=0x9f68b08, targettype=0x9f68b20,
>> econtext=0x9f68928, values=0x9f68c00, nulls=0x9f68c18 "",
>> itemIsDone=0x9f68c30, isDone=0xfeffb46c) at execQual.c:2984
>> #39 0x0810a12a in ExecProject (projInfo=0x0, isDone=0x800) at execQual.c:3130
>> #40 0x08111f95 in ExecResult (node=0x9f688a0) at nodeResult.c:155
>> #41 0x08106089 in ExecProcNode (node=0x9f688a0) at execProcnode.c:295
>> #42 0x08104a1d in ExecutePlan (estate=0x9f68790, planstate=0x9f688a0,
>> operation=CMD_SELECT, numberTuples=0, direction=2048, dest=0x94364a8)
>> at execMain.c:1100
>> #43 0x08103df8 in ExecutorRun (queryDesc=0x94578a8,
>> direction=ForwardScanDirection, count=2048) at execMain.c:249
>> #44 0x0817b07b in PortalRunSelect (portal=0x9439c10, forward=0 '\0', count=0,
>> dest=0x94364a8) at pquery.c:590
>> #45 0x0817ae53 in PortalRun (portal=0x9439c10, count=2147483647,
>> dest=0x94364a8, altdest=0x800, completionTag=0xfeffb630 "") at pquery.c:478
>> #46 0x081777e5 in exec_simple_query (
>> query_string=0x9435c00 "SELECT custSprtRpt ('09/27/06','09/27/06')")
>> at postgres.c:873
>> #47 0x08179f09 in PostgresMain (argc=4, argv=0x93e7608,
>> username=0x93e7578 "chuck") at postgres.c:2871
>> #48 0x08153c90 in BackendFork (port=0x93fa810) at postmaster.c:2564
>> #49 0x08153683 in BackendStartup (port=0x93fa810) at postmaster.c:2207
>> #50 0x08151be8 in ServerLoop () at postmaster.c:1119
>> #51 0x081512ae in PostmasterMain (argc=5, argv=0x93e6688) at postmaster.c:897
>> #52 0x08121163 in main (argc=5, argv=0xfeffc6b4) at main.c:214
>>
>> --------------020607020903010406060907
>> Content-Type: text/plain
>> Content-Transfer-Encoding: 8bit
>> X-Google-AttachSize: 169
>>
>>
>> ---------------------------(end of broadcast)---------------------------
>> TIP 3: Have you checked our extensive FAQ?
>>
>> http://www.postgresql.org/docs/faq
>>
>> --------------020607020903010406060907--
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>

--
Until later, Geoffrey

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
- Benjamin Franklin