[postgis-devel] Met Postgres crash while using postgis

Darafei "Komяpa" Praliaskouski me at komzpa.net
Thu Jul 19 04:57:47 PDT 2018


Please upgrade to 2.2.7 or better 2.4.4 that have lexer memory corruption
fixed.

News:
https://svn.osgeo.org/postgis/tags/2.4.4/NEWS

On чц, 19 ліп 2018, 14:32 <benjamin2037 at sina.com> wrote:

> Hi
> ​We use Postgres9.4 and postgis 2.2.2, one of our customer report they met
> to crash while issue the below query.
> SELECT guid, ST_X(location :: GEOMETRY) AS lng, ST_Y(location :: GEOMETRY)
> AS lat
> FROM xxx
> WHERE city_guid = 'xxx'
> AND no_use IS NOT TRUE
> and pending_num >= 0
> AND _ST_Covers(ST_SetSRID('POLYGON((121.23592586538606
> 37.5788252744999,121.23592586538606 37.55599397911481,121.25212104314092
> 37.55599397911481,121.25212104314092 37.5788252744999,121.23592586538606
> 37.5788252744999))'::TEXT, 4326), location);
> The create table statement list below:
> CREATE TABLE t_recycle (
> guid character varying(36) NOT NULL,
> xxx_guid character varying(36) NOT NULL,
> xxx_name character varying(10) NOT NULL,
> address character varying(100),
> location geography(Point,4326) NOT NULL,
> location_hash character varying(32) NOT NULL,
> t_num integer DEFAULT 0 NOT NULL,
> x_num integer DEFAULT 0 NOT NULL,
> create_date timestamp without time zone,
> update_date timestamp without time zone,
> remark character varying(100),
> image_url jsonb,
> create_user_name character varying(10),
> create_user_guid character varying(36),
> update_user_guid character varying(36),
> update_user_name character varying(10),
> no_use boolean,
> mark_type smallint,
> CONSTRAINT pk_t_recycle PRIMARY KEY (guid)
> );
> the stack like this:
> Loaded symbols for /u01/pgsql_20171103/lib/plpgsql.so
> Core was generated by `postgres: bike_bos_rw bike_bos 10.81.55.17(42324)
> SELECT '.
> Program terminated with signal 11, Segmentation fault.
> #0 repalloc (pointer=0x34c3b30, size=72) at mcxt.c:745
> 745 mcxt.c: No such file or directory.
> in mcxt.c
> Missing separate debuginfos, use: debuginfo-install
> glibc-2.12-1.166.alios6.7.x86_64 libselinux-2.0.94-5.2.1.alios6.x86_64
> (gdb) bt
> #0 repalloc (pointer=0x34c3b30, size=72) at mcxt.c:745
> #1 0x00002ba42377e561 in wkt_yyensure_buffer_stack () at
> lwin_wkt_lex.c:1741
> #2 0x00002ba42377e789 in wkt_yy_switch_to_buffer (new_buffer=0x305c530) at
> lwin_wkt_lex.c:1521
> #3 0x00002ba42377e8d1 in wkt_yy_scan_buffer (
> base=0x305c420 "POLYGON((121.23592586538606
> 37.5788252744999,121.23592586538606 37.55599397911481,121.25212104314092
> 37.55599397911481,121.25212104314092 37.5788252744999,121.23592586538606
> 37.5788252744999))", size=<value optimized out>) at lwin_wkt_lex.c:1784
> #4 0x00002ba42377e957 in wkt_yy_scan_bytes (
> yybytes=0x305c310 "POLYGON((121.23592586538606
> 37.5788252744999,121.23592586538606 37.55599397911481,121.25212104314092
> 37.55599397911481,121.25212104314092 37.5788252744999,121.23592586538606
> 37.5788252744999))", _yybytes_len=192) at lwin_wkt_lex.c:1828
> #5 0x00002ba42377e9d9 in wkt_lexer_init (src=<value optimized out>) at
> lwin_wkt_lex.l:19
> #6 0x00002ba42377e0bf in lwgeom_parse_wkt (parser_result=0x7fffa8a26d60,
> wktstr=0x305c310 "POLYGON((121.23592586538606
> 37.5788252744999,121.23592586538606 37.55599397911481,121.25212104314092
> 37.55599397911481,121.25212104314092 37.5788252744999,121.23592586538606
> 37.5788252744999))", parser_check_flags=7) at lwin_wkt_parse.y:67
> #7 0x00002ba42373b9ee in LWGEOM_in (fcinfo=0x7fffa8a26de0) at
> lwgeom_inout.c:122
> #8 0x00000000007e23ca in DirectFunctionCall1Coll (func=0x2ba42373b930
> <LWGEOM_in>, collation=<value optimized out>, arg1=<value optimized out>)
> at fmgr.c:1062
> #9 0x00002ba42373aa06 in parse_WKT_lwgeom (fcinfo=0x3231050) at
> lwgeom_inout.c:716
> #10 0x00000000005c24cc in ExecMakeFunctionResultNoSets (fcache=0x3230fe0,
> econtext=<value optimized out>, isNull=0x3230b80 "", isDone=<value
> optimized out>) at execQual.c:2026
> #11 ExecEvalFunc (fcache=0x3230fe0, econtext=<value optimized out>,
> isNull=0x3230b80 "", isDone=<value optimized out>) at execQual.c:2417
> #12 0x00000000005c245e in ExecMakeFunctionResultNoSets (fcache=0x32307d0,
> econtext=0x2bf1570, isNull=0x3230370 "", isDone=<value optimized out>) at
> execQual.c:2000
> #13 ExecEvalFunc (fcache=0x32307d0, econtext=0x2bf1570, isNull=0x3230370
> "", isDone=<value optimized out>) at execQual.c:2417
> #14 0x00000000005c245e in ExecMakeFunctionResultNoSets (fcache=0x322ffc0,
> econtext=0x2bf1570, isNull=0x322fb60 "", isDone=<value optimized out>) at
> execQual.c:2000
> #15 ExecEvalFunc (fcache=0x322ffc0, econtext=0x2bf1570, isNull=0x322fb60
> "", isDone=<value optimized out>) at execQual.c:2417
> #16 0x00000000005c245e in ExecMakeFunctionResultNoSets (fcache=0x322f7b0,
> econtext=0x2bf1570, isNull=0x7fffa8a273ff "", isDone=<value optimized out>)
> at execQual.c:2000
> #17 ExecEvalFunc (fcache=0x322f7b0, econtext=0x2bf1570,
> isNull=0x7fffa8a273ff "", isDone=<value optimized out>) at execQual.c:2417
> #18 0x00000000005bbbce in ExecQual (qual=<value optimized out>,
> econtext=0x2bf1570, resultForNull=<value optimized out>) at execQual.c:5236
> #19 0x00000000005c275f in ExecScan (node=0x2bf1600, accessMtd=0x5cb340
> <BitmapHeapNext>, recheckMtd=0x5cb2f0 <BitmapHeapRecheck>) at execScan.c:195
> #20 0x00000000005bb2b8 in ExecProcNode (node=0x2bf1600) at
> execProcnode.c:414
> #21 0x00000000005b9475 in ExecutePlan (queryDesc=0x1f18bb8,
> direction=<value optimized out>, count=0) at execMain.c:1490
> #22 standard_ExecutorRun (queryDesc=0x1f18bb8, direction=<value optimized
> out>, count=0) at execMain.c:319
> #23 0x00002b9fe76a632b in pgss_ExecutorRun (queryDesc=0x1f18bb8,
> direction=ForwardScanDirection, count=0) at pg_stat_statements.c:871
> #24 0x00002b9fe7aad635 in explain_ExecutorRun (queryDesc=0x1f18bb8,
> direction=ForwardScanDirection, count=0) at auto_explain.c:241
> #25 0x00000000006d5317 in PortalRunSelect (portal=0x106c680,
> forward=<value optimized out>, count=0, dest=<value optimized out>) at
> pquery.c:948
> #26 0x00000000006d5ff8 in PortalRun (portal=0x106c680,
> count=9223372036854775807, isTopLevel=1 '\001', dest=0x110e510,
> altdest=0x110e510, completionTag=0x7fffa8a27900 "") at pquery.c:790
> #27 0x00000000006d2589 in exec_execute_message (portal_name=0x110e100 "",
> max_rows=9223372036854775807) at postgres.c:2031
> #28 0x00000000006d43bc in PostgresMain (argc=<value optimized out>,
> argv=<value optimized out>, dbname=0x103d8f0 "bike_bos", username=<value
> optimized out>) at postgres.c:4362
> #29 0x000000000066bd5f in BackendRun (argc=<value optimized out>,
> argv=<value optimized out>) at postmaster.c:4300
> #30 BackendStartup (argc=<value optimized out>, argv=<value optimized
> out>) at postmaster.c:3963
> #31 ServerLoop (argc=<value optimized out>, argv=<value optimized out>) at
> postmaster.c:1693
> #32 PostmasterMain (argc=<value optimized out>, argv=<value optimized
> out>) at postmaster.c:1301
> #33 0x00000000005f474c in main (argc=3, argv=0x103c610) at main.c:233
> (gdb) f 1
> #1 0x00002ba42377e561 in wkt_yyensure_buffer_stack () at
> lwin_wkt_lex.c:1741
> 1741 lwin_wkt_lex.c: No such file or directory.
> in lwin_wkt_lex.c
> (gdb) p yy_buffer_stack
> $1 = (YY_BUFFER_STATE *) 0x34c3b30
> (gdb) p *yy_buffer_stack
> $2 = (YY_BUFFER_STATE) 0x0
> Since we can not re-produce the dump. Could you help to analyze the root
> cause? Thank you very much!
>
>
> Benjamin Xiong
> from Alibaba_______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel

-- 
Darafei Praliaskouski
Support me: http://patreon.com/komzpa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20180719/45eb9fbf/attachment-0001.html>


More information about the postgis-devel mailing list