pg.ddx.io pgsql-bugs@postgresql.org mailing list archivehelp / color / mirror / Atom feed
BUG #17022: SQL causing engine crash 3+ messages / 3 participants [nested] [flat]
* BUG #17022: SQL causing engine crash @ 2021-05-19 06:58 PG Bug reporting form <noreply@postgresql.org> 2021-05-19 14:50 ` Re: BUG #17022: SQL causing engine crash Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 1 reply; 3+ messages in thread From: PG Bug reporting form @ 2021-05-19 06:58 UTC (permalink / raw) To: pgsql-bugs@lists.postgresql.org; +Cc: tharakan@gmail.com 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 ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: BUG #17022: SQL causing engine crash 2021-05-19 06:58 BUG #17022: SQL causing engine crash PG Bug reporting form <noreply@postgresql.org> @ 2021-05-19 14:50 ` Tom Lane <tgl@sss.pgh.pa.us> 2021-05-21 02:52 ` Re: BUG #17022: SQL causing engine crash Robins Tharakan <tharakan@gmail.com> 0 siblings, 1 reply; 3+ messages in thread From: Tom Lane @ 2021-05-19 14:50 UTC (permalink / raw) To: tharakan@gmail.com; +Cc: pgsql-bugs@lists.postgresql.org 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 ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: BUG #17022: SQL causing engine crash 2021-05-19 06:58 BUG #17022: SQL causing engine crash PG Bug reporting form <noreply@postgresql.org> 2021-05-19 14:50 ` Re: BUG #17022: SQL causing engine crash Tom Lane <tgl@sss.pgh.pa.us> @ 2021-05-21 02:52 ` Robins Tharakan <tharakan@gmail.com> 0 siblings, 0 replies; 3+ messages in thread From: Robins Tharakan @ 2021-05-21 02:52 UTC (permalink / raw) To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-bugs@lists.postgresql.org 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 ^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2021-05-21 02:52 UTC | newest] Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2021-05-19 06:58 BUG #17022: SQL causing engine crash PG Bug reporting form <noreply@postgresql.org> 2021-05-19 14:50 ` Tom Lane <tgl@sss.pgh.pa.us> 2021-05-21 02:52 ` Robins Tharakan <tharakan@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox