Обсуждение: BUG #17022: SQL causing engine crash

Поиск
Список
Период
Сортировка

BUG #17022: SQL causing engine crash

От
PG Bug reporting form
Дата:
The following bug has been logged on the website:

Bug reference:      17022
Logged by:          Robins Tharakan
Email address:      tharakan@gmail.com
PostgreSQL version: 13.3
Operating system:   Amazon Linux 2
Description:

Hi,

SQLSmith is constantly crashing v13.3 with SQL(s) that appear linked to a
PostGIS (v3.0.3) bug - see Error Report below.

I decided to post this here (backtracking on an earlier thought), since #0 /
#1 are postgres functions and I wasn't really sure if the arguments to these
functions are sanitized. For e.g. whether pg_detoast_datum_slice() is
expected to check input bounds (count=40 in this case).

Sample SQL (I couldn't narrow this down further):
==========
$ psql
psql (13beta2, server 13.3)
Type "help" for help.

regression=>   select 1
from public.spatial_ref_sys as sample_0 tablesample bernoulli (6.8)
where case when ((cast(null as geometry) && cast(null as geometry))
        and (NULL is NULL))
       then case when sample_0.auth_srid is NULL then cast(null as geometry)
else cast(null as geometry) end
       else case when sample_0.auth_srid is NULL then cast(null as geometry)
else cast(null as geometry) end
       end
     &/& case when (pg_catalog.pg_current_snapshot() is not NULL)
      and (cast(null as timestamptz) >= (select backend_start from
pg_catalog.pg_stat_activity limit 1 offset 4)
          ) then public.geometry(
      cast(cast(null as geography) as geography)) else public.geometry(
      cast(cast(null as geography) as geography)) end;
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.




Another Example:
==============
SELECT 1 FROM (SELECT NULL::int a LIMIT 0) AS ref_0
WHERE CASE
    WHEN CASE
        WHEN pg_catalog.jsonb_build_array() ? version()
          THEN cast(NULL AS point)
        ELSE cast(NULL AS point)
        END @(SELECT NULL::lseg LIMIT 0)
      THEN cast(NULL AS GEOGRAPHY)
    END && CASE
    WHEN (
        CASE
          WHEN ref_0.a IS NULL
          THEN cast(NULL AS float4)
          ELSE cast(NULL AS float4)
        END <= (
          SELECT NULL::real LIMIT 0
          )
        )
      THEN NULL::GEOGRAPHY
    END
limit 58;




Backtrace (common to most such crashes):
========
#0  detoast_attr_slice (attr=attr@entry=0x0,
sliceoffset=sliceoffset@entry=0, slicelength=slicelength@entry=40) at
detoast.c:226
#1  0x00000000008a3b55 in pg_detoast_datum_slice (datum=datum@entry=0x0,
first=first@entry=0, count=count@entry=40) at fmgr.c:1754
#2  0x000014e217f4f793 in gserialized_datum_get_gidx_p
(gsdatum=gsdatum@entry=0, gidx=gidx@entry=0x7fffb1ba7730) at
gserialized_gist.c:185
#3  0x000014e217f4faa9 in gserialized_datum_get_gbox_p (gsdatum=0,
gbox=gbox@entry=0x7fffb1ba77d0) at gserialized_gist.c:157
#4  0x000014e217ef971b in gserialized_sel_internal (root=<optimized out>,
args=<optimized out>, varRelid=<optimized out>, mode=0) at
gserialized_estimate.c:2253
#5  0x000014e217ef9799 in gserialized_gist_sel
(fcinfo=fcinfo@entry=0x7fffb1ba7850) at gserialized_estimate.c:2281
#6  0x00000000008a24f4 in DirectFunctionCall5Coll
(func=func@entry=0x14e217ef9780 <gserialized_gist_sel>,
collation=collation@entry=0, arg1=<optimized out>,
    arg2=<optimized out>, arg3=<optimized out>, arg4=<optimized out>,
arg5=0) at fmgr.c:908
#7  0x000014e217ef96a4 in gserialized_gist_sel_nd (fcinfo=<optimized out>)
at gserialized_estimate.c:2204
#8  0x00000000008a2c6e in FunctionCall4Coll (flinfo=0x7fffb1ba7970,
collation=<optimized out>, arg1=<optimized out>, arg2=<optimized out>,
arg3=<optimized out>,
    arg4=<optimized out>) at fmgr.c:1216
#9  0x00000000008a3247 in OidFunctionCall4Coll (functionId=<optimized out>,
collation=collation@entry=0, arg1=arg1@entry=49189016,
arg2=arg2@entry=1118028,
    arg3=arg3@entry=50164232, arg4=arg4@entry=0) at fmgr.c:1452
#10 0x000000000070b45d in restriction_selectivity
(root=root@entry=0x2ee9098, operatorid=1118028, args=0x2fd7208,
inputcollid=0, varRelid=varRelid@entry=0)
    at plancat.c:1785


Reference:
a) PostGIS Bug report - https://trac.osgeo.org/postgis/ticket/4919

-
Robins
AWS Database Engineer


Re: BUG #17022: SQL causing engine crash

От
Tom Lane
Дата:
PG Bug reporting form <noreply@postgresql.org> writes:
> SQLSmith is constantly crashing v13.3 with SQL(s) that appear linked to a
> PostGIS (v3.0.3) bug - see Error Report below.

Yeah, I agree, it's a postgis bug.

> I decided to post this here (backtracking on an earlier thought), since #0 /
> #1 are postgres functions and I wasn't really sure if the arguments to these
> functions are sanitized. For e.g. whether pg_detoast_datum_slice() is
> expected to check input bounds (count=40 in this case).

The trace shows that gserialized_datum_get_gidx_p is passing a NULL
datum pointer to pg_detoast_datum_slice.  Whether the slice length
is appropriate seems like an academic question.

(It does look like that code validates sliceoffset and slicelength
and does something appropriate if they're outside the bounds of
the datum's size.  But you gotta have a datum.)

            regards, tom lane



Re: BUG #17022: SQL causing engine crash

От
Robins Tharakan
Дата:
On Thu, 20 May 2021 at 00:50, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> PG Bug reporting form <noreply@postgresql.org> writes:
> > SQLSmith is constantly crashing v13.3 with SQL(s) that appear linked to a
> > PostGIS (v3.0.3) bug - see Error Report below.
>
> Yeah, I agree, it's a postgis bug.

Thanks for a prompt confirmation / clarifying on the probable cause.
-
robins