[postgis-tickets] [PostGIS] #4652: Postgres crash with ST_GeomFromGML

PostGIS trac at osgeo.org
Fri Mar 27 08:09:15 PDT 2020 

#4652: Postgres crash with ST_GeomFromGML
-------------------------+----------------------------
  Reporter:  mwjhartogs  |      Owner:  pramsey
      Type:  defect      |     Status:  new
  Priority:  critical    |  Milestone:
 Component:  postgis     |    Version:  2.5.x
Resolution:              |   Keywords:  ST_GeomFromGML
-------------------------+----------------------------

Comment (by Algunenano):

 Call stack without any optimizations (neither PG nor Postgis):

 {{{
 (gdb) bt
 #0  0x00007fba0f042ce5 in raise () from /usr/lib/libc.so.6
 #1  0x00007fba0f02c857 in abort () from /usr/lib/libc.so.6
 #2  0x00007fba0f0862b0 in __libc_message () from /usr/lib/libc.so.6
 #3  0x00007fba0f08d74a in malloc_printerr () from /usr/lib/libc.so.6
 #4  0x00007fba0f0906b4 in _int_malloc () from /usr/lib/libc.so.6
 #5  0x00007fba0f091e74 in malloc () from /usr/lib/libc.so.6
 #6  0x0000559e4bc1d52e in AllocSetAlloc (context=0x559e4c58b6e0, size=128)
 at aset.c:914
 #7  0x0000559e4bc29d71 in MemoryContextAllocZeroAligned
 (context=0x559e4c58b6e0, size=128) at mcxt.c:864
 #8  0x0000559e4b8c2feb in standard_planner (parse=0x559e4c58c928,
 cursorOptions=256, boundParams=0x0) at planner.c:298
 #9  0x0000559e4b8c2fae in planner (parse=0x559e4c58c928,
 cursorOptions=256, boundParams=0x0) at planner.c:275
 #10 0x0000559e4ba0510c in pg_plan_query (querytree=0x559e4c58c928,
 cursorOptions=256, boundParams=0x0) at postgres.c:878
 #11 0x0000559e4ba05270 in pg_plan_queries (querytrees=0x559e4c58d698,
 cursorOptions=256, boundParams=0x0) at postgres.c:968
 #12 0x0000559e4bbc58b6 in BuildCachedPlan (plansource=0x559e4c58c698,
 qlist=0x559e4c58d698, boundParams=0x0, queryEnv=0x0) at plancache.c:933
 #13 0x0000559e4bbc4db7 in GetCachedPlan (plansource=0x559e4c58c698,
 boundParams=0x0, useResOwner=false, queryEnv=0x0) at plancache.c:1214
 #14 0x0000559e4b7ff3ad in _SPI_execute_plan (plan=0x7ffe8b63d5d0,
 paramLI=0x0, snapshot=0x0, crosscheck_snapshot=0x0, read_only=false,
 fire_triggers=true, tcount=1) at spi.c:2215
 #15 0x0000559e4b7fef4b in SPI_execute (src=0x7ffe8b63d660 "SELECT
 position('+units=m ' in proj4text)", ' ' <repeats 25 times>, "FROM
 spatial_ref_sys WHERE srid='28992'", read_only=false, tcount=1) at
 spi.c:514
 #16 0x0000559e4b7ffbd1 in SPI_exec (src=0x7ffe8b63d660 "SELECT
 position('+units=m ' in proj4text)", ' ' <repeats 25 times>, "FROM
 spatial_ref_sys WHERE srid='28992'", tcount=1) at spi.c:526
 #17 0x00007fb7feb59274 in gml_is_srid_planar (srid=28992) at
 lwgeom_in_gml.c:397
 #18 0x00007fb7feb56ccd in parse_gml_srs (xnode=0x559e4c558c30,
 srs=0x7ffe8b63d850) at lwgeom_in_gml.c:487
 #19 0x00007fb7feb57455 in parse_gml_curve (xnode=0x559e4c558c30,
 hasz=0x7ffe8b63d917, root_srid=0x7ffe8b63d910) at lwgeom_in_gml.c:1138
 #20 0x00007fb7feb565e4 in parse_gml (xnode=0x559e4c558c30,
 hasz=0x7ffe8b63d917, root_srid=0x7ffe8b63d910) at lwgeom_in_gml.c:1933
 #21 0x00007fb7feb563a5 in lwgeom_from_gml (
     xml=0x559e4c55cdf0 "<gml:Curve id=\"id-
 69b216c9-2c07-434d-8664-e321b3697725-0\" srsDimension=\"2\"
 srsName=\"urn:x-ogc:def:crs:EPSG:28992\"> <gml:segments>
 <gml:LineStringSegment> \n<gml:posList>119675.91899999976
 526436.120999"..., xml_size=13248)
     at lwgeom_in_gml.c:1877
 #22 0x00007fb7feb56276 in geom_from_gml (fcinfo=0x559e4c5424d0) at
 lwgeom_in_gml.c:116
 #23 0x0000559e4b798735 in ExecInterpExpr (state=0x559e4c5423e0,
 econtext=0x559e4c542620, isnull=0x7ffe8b63dc87) at execExprInterp.c:649
 #24 0x0000559e4b7979d7 in ExecInterpExprStillValid (state=0x559e4c5423e0,
 econtext=0x559e4c542620, isNull=0x7ffe8b63dc87) at execExprInterp.c:1778
 #25 0x0000559e4b8ec46b in ExecEvalExprSwitchContext (state=0x559e4c5423e0,
 econtext=0x559e4c542620, isNull=0x7ffe8b63dc87) at
 ../../../../src/include/executor/executor.h:307
 #26 0x0000559e4b8ec31f in evaluate_expr (expr=0x559e4c4762b8,
 result_type=72111, result_typmod=-1, result_collation=0) at clauses.c:4812
 #27 0x0000559e4b8ee0e9 in evaluate_function (funcid=72624,
 result_type=72111, result_typmod=-1, result_collid=0, input_collid=100,
 args=0x559e4c476200, funcvariadic=false, func_tuple=0x7fb7fecf1ed0,
 context=0x7ffe8b63fa80) at clauses.c:4354
 #28 0x0000559e4b8ed388 in simplify_function (funcid=72624,
 result_type=72111, result_typmod=-1, result_collid=0, input_collid=100,
 args_p=0x7ffe8b63e328, funcvariadic=false, process_args=true,
 allow_non_const=true, context=0x7ffe8b63fa80)
     at clauses.c:3984
 #29 0x0000559e4b8e939b in eval_const_expressions_mutator
 (node=0x559e4c475ed8, context=0x7ffe8b63fa80) at clauses.c:2477
 #30 0x0000559e4b8352ff in expression_tree_mutator (node=0x559e4c475f30,
 mutator=0x559e4b8e8e70 <eval_const_expressions_mutator>,
 context=0x7ffe8b63fa80) at nodeFuncs.c:2963
 #31 0x0000559e4b8eb86f in eval_const_expressions_mutator
 (node=0x559e4c475f30, context=0x7ffe8b63fa80) at clauses.c:3539
 #32 0x0000559e4b835514 in expression_tree_mutator (node=0x559e4c475718,
 mutator=0x559e4b8e8e70 <eval_const_expressions_mutator>,
 context=0x7ffe8b63fa80) at nodeFuncs.c:3012
 #33 0x0000559e4b8eb86f in eval_const_expressions_mutator
 (node=0x559e4c475718, context=0x7ffe8b63fa80) at clauses.c:3539
 #34 0x0000559e4b8e8e3e in eval_const_expressions (root=0x559e4c474508,
 node=0x559e4c475718) at clauses.c:2269
 #35 0x0000559e4b8c4ca8 in preprocess_expression (root=0x559e4c474508,
 expr=0x559e4c475718, kind=1) at planner.c:1087
 #36 0x0000559e4b8c3e8a in subquery_planner (glob=0x559e4c475aa8,
 parse=0x559e4c475448, parent_root=0x0, hasRecursion=false,
 tuple_fraction=0) at planner.c:769
 #37 0x0000559e4b8c3216 in standard_planner (parse=0x559e4c475448,
 cursorOptions=256, boundParams=0x0) at planner.c:406
 #38 0x0000559e4b8c2fae in planner (parse=0x559e4c475448,
 cursorOptions=256, boundParams=0x0) at planner.c:275
 #39 0x0000559e4ba0510c in pg_plan_query (querytree=0x559e4c475448,
 cursorOptions=256, boundParams=0x0) at postgres.c:878
 #40 0x0000559e4ba05270 in pg_plan_queries (querytrees=0x559e4c476050,
 cursorOptions=256, boundParams=0x0) at postgres.c:968
 #41 0x0000559e4ba07ddb in exec_simple_query (
     query_string=0x559e4c49dbd0 "select ST_GeomFromGML('<gml:Curve id
 =\"id-69b216c9-2c07-434d-8664-e321b3697725-0\" srsDimension=\"2\"
 srsName=\"urn:x-ogc:def:crs:EPSG:28992\"> <gml:segments>
 <gml:LineStringSegment> \n<gml:posList>119675.91"...)
     at postgres.c:1143
 #42 0x0000559e4ba072ed in PostgresMain (argc=1, argv=0x559e4c4a5928,
 dbname=0x559e4c4a5778 "template_postgis", username=0x559e4c4a5750
 "postgres") at postgres.c:4247
 #43 0x0000559e4b9374bf in BackendRun (port=0x559e4c499e10) at
 postmaster.c:4437
 #44 0x0000559e4b936884 in BackendStartup (port=0x559e4c499e10) at
 postmaster.c:4128
 #45 0x0000559e4b935736 in ServerLoop () at postmaster.c:1704
 #46 0x0000559e4b932f24 in PostmasterMain (argc=3, argv=0x559e4c46e230) at
 postmaster.c:1377
 #47 0x0000559e4b82eee1 in main (argc=3, argv=0x559e4c46e230) at main.c:228
 }}}

 The fact that it is crashing in an internal allocation (inside
 pg_plan_query) points to a possible Postgresql bug, but it's not obvious
 to me why calling malloc(8192) might crash like this:
 {{{
 (gdb) f 6
 #6  0x0000559e4bc1d52e in AllocSetAlloc (context=0x559e4c58b6e0, size=128)
 at aset.c:914
 warning: Source file is more recent than executable.
 914                     block = (AllocBlock) malloc(blksize);
 (gdb) p blksize
 $1 = 8192
 }}}

-- 
Ticket URL: <https://trac.osgeo.org/postgis/ticket/4652#comment:3>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.

More information about the postgis-tickets mailing list