Re: [HACKERS] yet another query to crash the backend

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: t-ishii(at)sra(dot)co(dot)jp
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] yet another query to crash the backend
Date: 1998-09-21 04:09:44
Message-ID: 199809210409.AAA19046@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> \df command of psql crashes the backend.
>
> (\df generates following query)
>
> SELECT t.typname as result, p.proname as function,
> substr(oid8types(p.proargtypes),1,14) as arguments,
> substr(obj_description(p.oid),1,34) as description FROM pg_proc p,
> pg_type t WHERE p.prorettype = t.oid and (pronargs = 0 or
> oid8types(p.proargtypes) != '') ORDER BY result, function, arguments;

Is this on an empty database. I think this was fixed last week. Are
you seeing this with current sources?

>
> Here is the backtrace info.
>
> Program received signal SIGSEGV, Segmentation fault.
> 0xc76a7 in oid8types (oidArray=0x1bec94) at regproc.c:234
> 234 if (*sp != InvalidOid)
> (gdb) where
> #0 0xc76a7 in oid8types (oidArray=0x1bec94) at regproc.c:234
> #1 0xd3129 in fmgr_c (finfo=0x351198, values=0xefbfb12c, isNull=0xefbfb1cb "")
> at fmgr.c:104
> #2 0x3b56a in ExecMakeFunctionResult (node=0x2c5050, arguments=0x2c4250,
> econtext=0x2cb090, isNull=0xefbfb1cb "", isDone=0xefbfb1ff "\001P?,")
> at execQual.c:827
> #3 0x3b607 in ExecEvalFunc (funcClause=0x2c5010, econtext=0x2cb090,
> isNull=0xefbfb1cb "", isDone=0xefbfb1ff "\001P?,") at execQual.c:933
> #4 0x3b8c9 in ExecEvalExpr (expression=0x2c5010, econtext=0x2cb090,
> isNull=0xefbfb1cb "", isDone=0xefbfb1ff "\001P?,") at execQual.c:1222
> #5 0x3b324 in ExecEvalFuncArgs (fcache=0x351010, econtext=0x2cb090,
> argList=0x2c4270, argV=0xefbfb200, argIsDone=0xefbfb1ff "\001P?,")
> at execQual.c:631
> #6 0x3b416 in ExecMakeFunctionResult (node=0x2c3fd0, arguments=0x2c4270,
> econtext=0x2cb090, isNull=0xefbfb2d7 "",
> isDone=0xefbfb24f "\001p$B2?o8(B8\003") at execQual.c:714
> #7 0x3b5ba in ExecEvalOper (opClause=0x2c3f90, econtext=0x2cb090,
> isNull=0xefbfb2d7 "") at execQual.c:889
> #8 0x3b8b8 in ExecEvalExpr (expression=0x2c3f90, econtext=0x2cb090,
> isNull=0xefbfb2d7 "", isDone=0xefbfb29b "\001$B<2?oX8(B\003")
> at execQual.c:1219
> #9 0x3b68f in ExecEvalOr (orExpr=0x2c3e50, econtext=0x2cb090,
> isNull=0xefbfb2d7 "") at execQual.c:1024
> #10 0x3b8d8 in ExecEvalExpr (expression=0x2c3e50, econtext=0x2cb090,
> isNull=0xefbfb2d7 "", isDone=0xefbfb2d6 "\001") at execQual.c:1225
> #11 0x3b96f in ExecQualClause (clause=0x2c3e50, econtext=0x2cb090)
> at execQual.c:1281
> #12 0x3b9ae in ExecQual (qual=0x2c9af0, econtext=0x2cb090) at execQual.c:1347
> #13 0x3bd4e in ExecScan (node=0x2c7510, accessMtd=0x41a30 <SeqNext>)
> at execScan.c:142
> #14 0x41b0b in ExecSeqScan (node=0x2c7510) at nodeSeqscan.c:130
> #15 0x3a186 in ExecProcNode (node=0x2c7510, parent=0x2c7690)
> at execProcnode.c:267
> #16 0x3fa93 in ExecHashJoinOuterGetTuple (node=0x2c7510, parent=0x2c7690,
> hjstate=0x2c7890) at nodeHashjoin.c:582
> #17 0x3f650 in ExecHashJoin (node=0x2c7690) at nodeHashjoin.c:208
> #18 0x3a226 in ExecProcNode (node=0x2c7690, parent=0x2c7710)
> at execProcnode.c:315
> #19 0xd7d61 in createfirstrun (node=0x2c7710) at psort.c:402
> #20 0xd7b38 in initialrun (node=0x2c7710) at psort.c:293
> #21 0xd79dc in psort_begin (node=0x2c7710, nkeys=3, key=0x2c7f10)
> at psort.c:155
> #22 0x41e49 in ExecSort (node=0x2c7710) at nodeSort.c:156
> #23 0x3a1d6 in ExecProcNode (node=0x2c7710, parent=0x2c7710)
> at execProcnode.c:295
> #24 0x39774 in ExecutePlan (estate=0x2c7790, plan=0x2c7710,
> parseTree=0x288790, operation=CMD_SELECT, numberTuples=0,
> direction=ForwardScanDirection, printfunc=0x36b0 <debugtup>)
> at execMain.c:734
> #25 0x39181 in ExecutorRun (queryDesc=0x2ca350, estate=0x2c7790, feature=3,
> count=0) at execMain.c:232
> #26 0xa890b in ProcessQueryDesc (queryDesc=0x2ca350) at pquery.c:333
> #27 0xa8976 in ProcessQuery (parsetree=0x288790, plan=0x2c7710, dest=Debug)
> at pquery.c:376
> #28 0xa68ee in pg_exec_query_dest (
> query_string=0xefbfb5c0 "SELECT t.typname as result, p.proname as function, substr(oid8types(p.proargtypes),1,14) as arguments, substr(obj_description(p.oid),1,34) as description FROM pg_proc p, pg_type t WHERE p.prorettype ="...,
> dest=Debug, aclOverride=0) at postgres.c:798
> #29 0xa6784 in pg_exec_query (
> query_string=0xefbfb5c0 "SELECT t.typname as result, p.proname as function, substr(oid8types(p.proargtypes),1,14) as arguments, substr(obj_description(p.oid),1,34) as description FROM pg_proc p, pg_type t WHERE p.prorettype ="...)
> at postgres.c:697
> #30 0xa8128 in PostgresMain (argc=4, argv=0xefbfd60c, real_argc=4,
> real_argv=0xefbfd60c) at postgres.c:1611
> #31 0x4c96c in main (argc=4, argv=0xefbfd60c) at main.c:103
> (gdb)
> --
> Tatsuo Ishii
> t-ishii(at)sra(dot)co(dot)jp
>
>

--
Bruce Momjian | 830 Blythe Avenue
maillist(at)candle(dot)pha(dot)pa(dot)us | Drexel Hill, Pennsylvania 19026
http://www.op.net/~candle | (610) 353-9879(w)
+ If your life is a hard drive, | (610) 853-3000(h)
+ Christ can be your backup. |

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 1998-09-21 04:31:02 Re: [HACKERS] yet another query to crash the backend
Previous Message Tatsuo Ishii 1998-09-21 03:31:53 yet another query to crash the backend