Thread: Backend crash in opr_sanity regression test.

Hi Hackers,

With the following query from the opr_sanity regression test I'm
getting a backend crash.

SELECT p1.oid, p1.oprcode, p2.oid, p2.oprcode
FROM pg_operator AS p1, pg_operator AS p2
WHERE p1.oprlsortop = p2.oid AND   (p1.oprname != '=' OR    p1.oprkind != 'b' OR p2.oprkind != 'b' OR    p1.oprleft !=
p2.oprleftOR    p1.oprright != p2.oprright OR    p1.oprresult != 16 OR    p2.oprresult != 16 OR    p1.oprrsortop = 0);
 

This is on the latest CVS, although I believe it happened on earlier
snapshots.

Platform is SPARC/Linux Redhat 4.2 SPARCstation IPX.

I've not been able to investigate further.

Keith.

Here's a backtrace of the process:-    

Program received signal SIGSEGV, Segmentation fault.
0x76a44 in ExecScanHashBucket (hjstate=0x209b10, bucket=0x214d4c, curtuple=0x0, 
hjclauses=0x20add0,   econtext=0x20bc90) at nodeHash.c:734
734                             heapTuple->t_data = (HeapTupleHeader)
(gdb) bt
#0  0x76a44 in ExecScanHashBucket (hjstate=0x209b10, bucket=0x214d4c, 
curtuple=0x0, hjclauses=0x20add0,   econtext=0x20bc90) at nodeHash.c:734
#1  0x770e8 in ExecHashJoin (node=0x209c10) at nodeHashjoin.c:283
#2  0x7164c in ExecProcNode (node=0x209c10, parent=0x209c10) at 
execProcnode.c:315
#3  0x70ac4 in ExecutePlan (estate=0x209b90, plan=0x209c10, parseTree=0x1a5090, 
operation=CMD_SELECT,   numberTuples=0, direction=ForwardScanDirection, printfunc=0x28d08 
<printtup>) at execMain.c:733
#4  0x705a8 in ExecutorRun (queryDesc=0x209c10, estate=0x209b90, feature=3, 
count=0) at execMain.c:236
#5  0xd1130 in ProcessQueryDesc (queryDesc=0x20a8f0) at pquery.c:333
#6  0xd11a0 in ProcessQuery (parsetree=0x1a5090, plan=0x209c10, dest=Remote) at 
pquery.c:376
#7  0xcf8a0 in pg_exec_query_dest (   query_string=0xefffd1a0 "SELECT p1.oid, p1.oprcode, p2.oid, p2.oprcode\nFROM 
pg_operator AS p1, pg_operator AS p2\nWHERE p1.oprlsortop = p2.oid AND\n    
(p1.oprname != '=' OR\n     p1.oprkind != 'b' OR p2.oprkind != 'b' OR\n     
p"..., dest=Remote, aclOverride=0 '\000') at postgres.c:800
#8  0xcf730 in pg_exec_query (   query_string=0xefffd1a0 "SELECT p1.oid, p1.oprcode, p2.oid, p2.oprcode\nFROM 
pg_operator AS p1, pg_operator AS p2\nWHERE p1.oprlsortop = p2.oid AND\n    
(p1.oprname != '=' OR\n     p1.oprkind != 'b' OR p2.oprkind != 'b' OR\n     
p"...) at postgres.c:699
#9  0xd0a6c in PostgresMain (argc=-8192, argv=0x15dc00, real_argc=10, 
real_argv=0xeffffd84) at postgres.c:1645
#10 0xb34e8 in DoBackend (port=0x135400) at postmaster.c:1532
#11 0xb2f74 in BackendStartup (port=0x199c00) at postmaster.c:1303
#12 0xb23dc in ServerLoop () at postmaster.c:757
#13 0xb1f24 in PostmasterMain (argc=0, argv=0xeffffd84) at postmaster.c:563
#14 0x83580 in main (argc=10, argv=0xeffffd84) at main.c:93                     

Keith Parks <emkxp01@mtcc.demon.co.uk> writes:
> With the following query from the opr_sanity regression test I'm
> getting a backend crash.
> [ details snipped ]
> This is on the latest CVS, although I believe it happened on earlier
> snapshots.
> Platform is SPARC/Linux Redhat 4.2 SPARCstation IPX.

FWIW, I saw a backend crash in opr_sanity in an otherwise reasonably
successful attempt to build/test Postgres on SPARC/SunOS 4.1.4.  This
was with REL6_4 CVS sources around the start of December.  I didn't have
time to investigate it closely, but it does seem there's a platform-
dependent problem lurking in there somewhere.  (Wonder if it could be
specific to the SPARC hardware?)

Can any of the backend experts make any guesses from Keith's backtrace?
        regards, tom lane

Tom Lane wrote:
> 
> Keith Parks <emkxp01@mtcc.demon.co.uk> writes:
> > With the following query from the opr_sanity regression test I'm
> > getting a backend crash.
> > [ details snipped ]
> > This is on the latest CVS, although I believe it happened on earlier
> > snapshots.
> > Platform is SPARC/Linux Redhat 4.2 SPARCstation IPX.
> 
> FWIW, I saw a backend crash in opr_sanity in an otherwise reasonably
> successful attempt to build/test Postgres on SPARC/SunOS 4.1.4.  This
> was with REL6_4 CVS sources around the start of December.  I didn't have     ^^^^^^^^^^^^^^^
It's probably caused by new HeapTuple stuff, but I didn't
put it in 6_4 branch...

> time to investigate it closely, but it does seem there's a platform-
> dependent problem lurking in there somewhere.  (Wonder if it could be
> specific to the SPARC hardware?)
> 
> Can any of the backend experts make any guesses from Keith's backtrace?

Vadim

> Hi Hackers,
> 
> With the following query from the opr_sanity regression test I'm
> getting a backend crash.
> 
> SELECT p1.oid, p1.oprcode, p2.oid, p2.oprcode
> FROM pg_operator AS p1, pg_operator AS p2
> WHERE p1.oprlsortop = p2.oid AND
>     (p1.oprname != '=' OR
>      p1.oprkind != 'b' OR p2.oprkind != 'b' OR
>      p1.oprleft != p2.oprleft OR
>      p1.oprright != p2.oprright OR
>      p1.oprresult != 16 OR
>      p2.oprresult != 16 OR
>      p1.oprrsortop = 0);

I tried the query in the current development tree, and it returned zero
rows and did not crash.

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