Re: continued segmentation fault

From: "Bob" <luckyratfoot(at)gmail(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: continued segmentation fault
Date: 2006-09-28 02:54:35
Message-ID: 1159412075.860192.237880@m73g2000cwd.googlegroups.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Is there any reason can't update to a newer version. Like 8.x?
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--

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message David Fetter 2006-09-28 02:54:45 Re: dbi-link questions + patch
Previous Message Jorge Godoy 2006-09-28 02:48:20 Re: Documenting stored procedures and functions