Thread: BUG #17022: SQL causing engine crash
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
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
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.
> 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
-
robins