ST_GeomFromGeoJsonof invalid GeoJSON with missing type crashes server process

[pdmaseberg]

Running the following query in which the crs has a missing type that is empty

SELECT ST_GeomFromGeoJson('{"type":"Point","crs"
 :{"type":""},"coordinates":[-97.3361,37.6914]}');​

Gives the output of

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.

I have seen this on the following versions

PostgreSQL 9.4.0 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-11), 64-bit POSTGIS="2.1.5 r13152" GEOS="3.4.2-CAPI-1.8.2 r3921" PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 1.9.2, released 2012/10/08" LIBXML="2.7.6" LIBJSON="UNKNOWN" RASTER

PostgreSQL 9.4.4 on x86_64-unknown-linux-gnu, compiled by gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2, 64-bit POSTGIS="2.1.7 r13414" GEOS="3.4.2-CAPI-1.8.2 r3921" PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 1.10.1, released 2013/08/26" LIBXML="2.9.1" LIBJSON="UNKNOWN" RASTER

PostgreSQL 9.4.4 on x86_64-unknown-linux-gnu, compiled by gcc (Ubuntu 4.9.2-10ubuntu13) 4.9.2, 64-bit POSTGIS="2.1.5 r13152" GEOS="3.4.2-CAPI-1.8.2 r3921" PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 1.11.2, released 2015/02/10" LIBXML="2.9.2" LIBJSON="UNKNOWN" RASTER

[robe]

Hmm I can't trigger this error on my Ubuntu server running PostGIS 2.1.5:

POSTGIS="2.1.5 r13152" GEOS="3.4.2-CAPI-1.8.2 r3921" PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 1.11.2, released 2015/02/10" LIBXML="2.9.2" LIBJSON="UNKNOWN" RASTER

PostgreSQL 9.4.4 on x86_64-unknown-linux-gnu, compiled by gcc (Ubuntu 4.9.2-10ubuntu13) 4.9.2, 64-bit

I think similar issues like this were fixed in PostGIS 2.1.8 so I would suggest upgrading and see if you get the same error.

On my PostGIS 2.2.0 and 2.1.8 installs (and my 2.1.5 ubuntu install), I just get error:

ERROR:  syntax error at or near "​"
LINE 1: ...int","crs":{"type":""},"coordinates":[-97.3361,37.6914]}');​

So it could be an issue too with libjson library being used as well which might explain why the error doesn't happen on my 2.1.5. Or the code you posted is the the one crashing.

[pdmaseberg]

I got the latest version of libjson-c.so and used LD_PRELOAD and it still crashes. I did get a stack trace of the crash and attached it. I am not sure how I have can have the exact same version as your Ubuntu server and have it crash while you cannot. I guess I don't follow how your libjson is setup different. Anyway I will keep looking at it, just wanted to post that stacktrace incase it is helpfully.

Program received signal SIGSEGV, Segmentation fault.
strlen () at ../sysdeps/x86_64/strlen.S:106
106	../sysdeps/x86_64/strlen.S: No such file or directory.
(gdb) where
#0  strlen () at ../sysdeps/x86_64/strlen.S:106
#1  0x00007f5a2d5bd4ff in lwgeom_from_geojson () from /usr/lib/liblwgeom-2.1.7.so
#2  0x00007f5a2d8237dd in geom_from_geojson () from /usr/lib/postgresql/9.4/lib/postgis-2.1.so
#3  0x00007f5a4013d933 in ExecMakeFunctionResultNoSets (fcache=0x7f5a419ae590, econtext=0x7f5a419aee20, isNull=0x7ffc072902dc "", isDone=<optimized out>)
    at /tmp/buildd/postgresql-9.4-9.4.4/build/../src/backend/executor/execQual.c:2026
#4  0x00007f5a40141e41 in ExecEvalExprSwitchContext (expression=expression@entry=0x7f5a419ae590, econtext=<optimized out>, isNull=isNull@entry=0x7ffc072902dc "", isDone=isDone@entry=0x0)
    at /tmp/buildd/postgresql-9.4-9.4.4/build/../src/backend/executor/execQual.c:4360
#5  0x00007f5a401bce0e in evaluate_expr (expr=<optimized out>, result_type=result_type@entry=258914, result_typmod=result_typmod@entry=-1, result_collation=result_collation@entry=0)
    at /tmp/buildd/postgresql-9.4-9.4.4/build/../src/backend/optimizer/util/clauses.c:4575
#6  0x00007f5a401be852 in evaluate_function (func_tuple=0x7f5a406847a8, context=0x7ffc07290640, funcvariadic=0 '\000', args=0x7f5a419f8400, input_collid=100, result_collid=0, result_typmod=-1, 
    result_type=258914, funcid=259353) at /tmp/buildd/postgresql-9.4-9.4.4/build/../src/backend/optimizer/util/clauses.c:4136
#7  simplify_function (funcid=259353, result_type=258914, result_typmod=-1, result_collid=result_collid@entry=0, input_collid=input_collid@entry=100, args_p=args_p@entry=0x7ffc07290458, 
    funcvariadic=funcvariadic@entry=0 '\000', process_args=process_args@entry=1 '\001', allow_non_const=allow_non_const@entry=1 '\001', context=context@entry=0x7ffc07290640)
    at /tmp/buildd/postgresql-9.4-9.4.4/build/../src/backend/optimizer/util/clauses.c:3775
#8  0x00007f5a401bf8cc in eval_const_expressions_mutator (node=0x7f5a419f8020, context=0x7ffc07290640) at /tmp/buildd/postgresql-9.4-9.4.4/build/../src/backend/optimizer/util/clauses.c:2459
#9  0x00007f5a401726cc in expression_tree_mutator (node=node@entry=0x7f5a419f8070, mutator=mutator@entry=0x7f5a401bf010 <eval_const_expressions_mutator>, context=context@entry=0x7ffc07290640)
    at /tmp/buildd/postgresql-9.4-9.4.4/build/../src/backend/nodes/nodeFuncs.c:2629
#10 0x00007f5a401bf422 in eval_const_expressions_mutator (node=0x7f5a419f8070, context=0x7ffc07290640) at /tmp/buildd/postgresql-9.4-9.4.4/build/../src/backend/optimizer/util/clauses.c:3428
#11 0x00007f5a4017233b in expression_tree_mutator (node=node@entry=0x7f5a419f7c48, mutator=mutator@entry=0x7f5a401bf010 <eval_const_expressions_mutator>, context=context@entry=0x7ffc07290640)
    at /tmp/buildd/postgresql-9.4-9.4.4/build/../src/backend/nodes/nodeFuncs.c:2560
#12 0x00007f5a401bf422 in eval_const_expressions_mutator (node=0x7f5a419f7c48, context=context@entry=0x7ffc07290640) at /tmp/buildd/postgresql-9.4-9.4.4/build/../src/backend/optimizer/util/clauses.c:3428
#13 0x00007f5a401c0950 in eval_const_expressions (root=root@entry=0x7f5a419f81a0, node=<optimized out>) at /tmp/buildd/postgresql-9.4-9.4.4/build/../src/backend/optimizer/util/clauses.c:2301
#14 0x00007f5a401adae7 in preprocess_expression (root=root@entry=0x7f5a419f81a0, expr=<optimized out>, kind=kind@entry=1) at /tmp/buildd/postgresql-9.4-9.4.4/build/../src/backend/optimizer/plan/planner.c:675
#15 0x00007f5a401b12b4 in subquery_planner (glob=glob@entry=0x7f5a419f7a98, parse=parse@entry=0x7f5a419f7808, parent_root=parent_root@entry=0x0, hasRecursion=hasRecursion@entry=0 '\000', tuple_fraction=0, 
    subroot=subroot@entry=0x7ffc07290748) at /tmp/buildd/postgresql-9.4-9.4.4/build/../src/backend/optimizer/plan/planner.c:423
#16 0x00007f5a401b18f1 in standard_planner (parse=0x7f5a419f7808, cursorOptions=0, boundParams=0x0) at /tmp/buildd/postgresql-9.4-9.4.4/build/../src/backend/optimizer/plan/planner.c:210
#17 0x00007f5a4022e9b4 in pg_plan_query (querytree=<optimized out>, cursorOptions=cursorOptions@entry=0, boundParams=boundParams@entry=0x0)
    at /tmp/buildd/postgresql-9.4-9.4.4/build/../src/backend/tcop/postgres.c:777
#18 0x00007f5a4022eaa4 in pg_plan_queries (querytrees=<optimized out>, cursorOptions=cursorOptions@entry=0, boundParams=boundParams@entry=0x0)
    at /tmp/buildd/postgresql-9.4-9.4.4/build/../src/backend/tcop/postgres.c:836
#19 0x00007f5a40230d0f in exec_simple_query (query_string=0x7f5a419f68d0 "SELECT ST_GeomFromGeoJson('{\"type\":\"Point\",\"crs\"\n :{\"type\":\"\"},\"coordinates\":[-97.3361,37.6914]}');")
    at /tmp/buildd/postgresql-9.4-9.4.4/build/../src/backend/tcop/postgres.c:1001
#20 PostgresMain (argc=<optimized out>, argv=argv@entry=0x7f5a419726c0, dbname=0x7f5a41972560 "client_store_dev", username=<optimized out>)
    at /tmp/buildd/postgresql-9.4-9.4.4/build/../src/backend/tcop/postgres.c:4074
#21 0x00007f5a4000202d in BackendRun (port=0x7f5a419b2460) at /tmp/buildd/postgresql-9.4-9.4.4/build/../src/backend/postmaster/postmaster.c:4164
#22 BackendStartup (port=0x7f5a419b2460) at /tmp/buildd/postgresql-9.4-9.4.4/build/../src/backend/postmaster/postmaster.c:3829
#23 ServerLoop () at /tmp/buildd/postgresql-9.4-9.4.4/build/../src/backend/postmaster/postmaster.c:1597
#24 0x00007f5a401dc001 in PostmasterMain (argc=5, argv=<optimized out>) at /tmp/buildd/postgresql-9.4-9.4.4/build/../src/backend/postmaster/postmaster.c:1244
#25 0x00007f5a40002d5d in main (argc=5, argv=0x7f5a41971760) at /tmp/buildd/postgresql-9.4-9.4.4/build/../src/backend/main/main.c:228

[robe]

Okay I think I got it. What you have seems to have gotten managled. I looked at the stack trace you have and constructed this

-- this gives error
SELECT ST_GeomFromGeoJson('{"type":"Point","crs":{"type":""},"coordinates":[-97.3361,37.6914]}');​

-- ERROR:  syntax error at or near "​"
LINE 1: ...int","crs":{"type":""},"coordinates":[-97.3361,37.6914]}');​

-- this crashes the backend on Ubuntu 2.1.5 and windows 2.1.7
SELECT ST_GeomFromGeoJson('{"type":"Point","crs":{"type":""},"coordinates":[-97.3361,37.6914]}');

I don't see a difference between the two at a glance so must be some unprintable character and with that my postgres crashes on my Ubuntu install. As luck would have it, I do have a windows box that is running 2.1.7 (and it crashes there too).

Whatever the issue is must be fixed in 2.1.8 though because y windows 2.2.0dev and windows 2.1.8 installs do not crash.

-- on 2.1.8 / 2.2.0 yields
SELECT ST_GeomFromGeoJson('{"type":"Point","crs":{"type":""},"coordinates":[-97.3361,37.6914]}');

-- yields --
0101000000E10B93A9825558C02A3A92CB7FD84240

SELECT ST_AsText(ST_GeomFromGeoJson('{"type":"Point","crs":{"type":""},"coordinates":[-97.3361,37.6914]}'));

--yields
POINT(-97.3361 37.6914)

So I'm going to mark this as fixed in 2.1.8