Re: [sqlsmith] Segfault in expand_tuple

On 04/07/2018 03:28 PM, Andreas Seltenreich wrote:
> Hi,
>
> the following query triggers a segfault for me when run against the
> regression database.  Testing was done with master at 039eb6e92f.
> Backtrace below.
>
[large query]

> Core was generated by `postgres: smith regression [local] SELECT  '.
> Program terminated with signal SIGSEGV, Segmentation fault.
> (gdb) bt
> #0  0x0000556c14759cb8 in expand_tuple (targetHeapTuple=targetHeapTuple@entry=0x0, 
>     targetMinimalTuple=targetMinimalTuple@entry=0x7ffe8088a118, sourceTuple=<optimized out>, tupleDesc=<optimized
out>)
>     at heaptuple.c:984
> #1  0x0000556c1475bb46 in minimal_expand_tuple (sourceTuple=<optimized out>, tupleDesc=<optimized out>) at
heaptuple.c:1015
> #2  0x0000556c14917177 in ExecCopySlotMinimalTuple (slot=<optimized out>) at execTuples.c:631
> #3  0x0000556c14ba8ada in copytup_heap (state=0x556c16c4f5e8, stup=0x7ffe8088a180, tup=<optimized out>) at
tuplesort.c:3585
> #4  0x0000556c14baf8e6 in tuplesort_puttupleslot (state=state@entry=0x556c16c4f5e8, slot=<optimized out>) at
tuplesort.c:1444
> #5  0x0000556c14937791 in ExecSort (pstate=0x556c16c3ac50) at nodeSort.c:112
> #6  0x0000556c1493c6f4 in ExecProcNode (node=0x556c16c3ac50) at ../../../src/include/executor/executor.h:239
> #7  begin_partition (winstate=winstate@entry=0x556c16c3a6b8) at nodeWindowAgg.c:1110
> #8  0x0000556c149403aa in ExecWindowAgg (pstate=0x556c16c3a6b8) at nodeWindowAgg.c:2094



Yeah, thanks for the report. An obvious fix is this where we treat any
case where attrmiss is entirely missing as meaning NULL for every
attribute we need to supply:

diff --git a/src/backend/access/common/heaptuple.c
b/src/backend/access/common/heaptuple.c
index c646456..b9802b9 100644
--- a/src/backend/access/common/heaptuple.c
+++ b/src/backend/access/common/heaptuple.c
@@ -981,7 +981,7 @@ expand_tuple(HeapTuple *targetHeapTuple,
 
        Form_pg_attribute attr = TupleDescAttr(tupleDesc, attnum);
 
-       if (attrmiss[attnum].ammissingPresent)
+       if (attrmiss && attrmiss[attnum].ammissingPresent)
        {
            fill_val(attr,
                     nullBits ? &nullBits : NULL,


although it might be a very small optimization to move the additional
test outside the loop.


I have cut down the query that generates the failure to this:

    select
        ref_0.a as c2,
        pg_catalog.stddev(
          cast((select pg_catalog.sum(float4col) from public.brintest)
    as float4))
           over (partition by ref_0.a,ref_0.b,ref_0.c order by ref_0.b)
        as c5
    from
      public.mlparted3 as ref_0;

Not sure if we want to produce something more self-contained for the
regression set. Clearly we should add something, as Tom has reminded me,
to make sure the code path is exercised.

cheers

andrew

-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services