\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;

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@sra.co.jp

Mon, 21 Sep 1998 12:31:53 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
yet another query to crash the backend
> \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@sra.co.jp
> 
> 


-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.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.        |

Mon, 21 Sep 1998 00:09:44 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] yet another query to crash the backend
>> \df command of psql crashes the backend.
>>=20
>> (\df generates following query)
>>=20
>> 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 =3D t.oid and (pronargs =3D 0 or
>> oid8types(p.proargtypes) !=3D '') 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?

No, this is BETA1. I will check current source.
--
Tatsuo Ishii
t-ishii@sra.co.jp

Mon, 21 Sep 1998 13:31:02 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
Re: [HACKERS] yet another query to crash the backend 