Opened 6 years ago

Closed 6 years ago

#2360 closed defect (fixed)

[raster]: ST_DumpAsPolygons database engine crash

Reported by: kafka Owned by: Bborie Park
Priority: critical Milestone: PostGIS 2.1.0
Component: raster Version: 2.0.x
Keywords: Cc:

Description

When executing ST_DumpAsPolygons, database engine crashes.

Example query:

SELECT (ST_DumpAsPolygons(
	ST_AsRaster(
		ST_GeomFromText('POLYGON((0 0,0 10,10 10,10 0,0 0))',4326), 100, 100, '2BUI'
	)
)).*

Environment:

  • postgis 2.0.3 (tested also on 2.0.1)
  • postgresql 9.1 (tested also on 9.2)
  • gdal 1.9.2
  • geos 3.3.8
  • debian 6 squeeze

Valgrind report:

==25861== Invalid free() / delete / delete[]
==25861==    at 0x4C23E0F: operator delete(void*) (vg_replace_malloc.c:387)
==25861==    by 0xDAD1488: OGRLIBKMLDriver::~OGRLIBKMLDriver() (in /usr/lib/libgdal.so.1.16.2)
==25861==    by 0xDB2CDF6: OGRSFDriverRegistrar::~OGRSFDriverRegistrar() (in /usr/lib/libgdal.so.1.16.2)
==25861==    by 0xDB2D5D8: OGRCleanupAll (in /usr/lib/libgdal.so.1.16.2)
==25861==    by 0xD14E3AD: rt_raster_gdal_rasterize (in /usr/lib/postgresql/9.1/lib/rtpostgis-2.0.so)
==25861==    by 0xD131279: RASTER_asRaster (in /usr/lib/postgresql/9.1/lib/rtpostgis-2.0.so)
==25861==    by 0x2BC08D: ??? (in /usr/lib/postgresql/9.1/bin/postgres)
==25861==    by 0x2B742D: ??? (in /usr/lib/postgresql/9.1/bin/postgres)
==25861==    by 0x2BBF48: ??? (in /usr/lib/postgresql/9.1/bin/postgres)
==25861==    by 0x2BA84D: ??? (in /usr/lib/postgresql/9.1/bin/postgres)
==25861==    by 0x2B713D: ExecProject (in /usr/lib/postgresql/9.1/bin/postgres)
==25861==    by 0x2CE46A: ExecResult (in /usr/lib/postgresql/9.1/bin/postgres)
==25861==  Address 0x8870af0 is 0 bytes inside a block of size 1 free'd
==25861==    at 0x4C23E0F: operator delete(void*) (vg_replace_malloc.c:387)
==25861==    by 0xDAD1488: OGRLIBKMLDriver::~OGRLIBKMLDriver() (in /usr/lib/libgdal.so.1.16.2)
==25861==    by 0xDB2CDF6: OGRSFDriverRegistrar::~OGRSFDriverRegistrar() (in /usr/lib/libgdal.so.1.16.2)
==25861==    by 0xDB2D5D8: OGRCleanupAll (in /usr/lib/libgdal.so.1.16.2)
==25861==    by 0xD14E3AD: rt_raster_gdal_rasterize (in /usr/lib/postgresql/9.1/lib/rtpostgis-2.0.so)
==25861==    by 0xD131279: RASTER_asRaster (in /usr/lib/postgresql/9.1/lib/rtpostgis-2.0.so)
==25861==    by 0x2BC08D: ??? (in /usr/lib/postgresql/9.1/bin/postgres)
==25861==    by 0x2B742D: ??? (in /usr/lib/postgresql/9.1/bin/postgres)
==25861==    by 0x2BBF48: ??? (in /usr/lib/postgresql/9.1/bin/postgres)
==25861==    by 0x2BA84D: ??? (in /usr/lib/postgresql/9.1/bin/postgres)
==25861==    by 0x2B713D: ExecProject (in /usr/lib/postgresql/9.1/bin/postgres)
==25861==    by 0x2CE46A: ExecResult (in /usr/lib/postgresql/9.1/bin/postgres)
==25861==

Change History (9)

comment:1 Changed 6 years ago by robe

Component: postgisraster
Owner: changed from pramsey to Bborie Park
Summary: ST_DumpAsPolygons database engine crash[raster]: ST_DumpAsPolygons database engine crash

comment:2 Changed 6 years ago by robe

kafka -- if you compile your own, can you try against the latest 2.0.4 SVN

This might be an issue that is fixed. I grabbed 3 installs I have handy.

-- crashes on this one --
-- but I've been fussing with this one like 
-- using GCC 4.8.0 so might not be a fair test
-- then again this one is also 
-- using an older subversion (r11306 which is older than the other 2) 
POSTGIS="2.1.0SVN r11306" GEOS="3.4.0dev-CAPI-1.8.0 r0" PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 1.9.2, released 2012/10/08 GDAL_DATA not found" LIBXML="2.7.8" LIBJSON="UNKNOWN" RASTER PostgreSQL 9.2.4, compiled by Visual C++ build 1600, 32-bit

It however doesn't crash on my windows 9.2.4s. 64-bit installs

POSTGIS="2.1.0beta3dev r11482" GEOS="3.4.0dev-CAPI-1.8.0 r0" PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 1.10.0, released 2013/04/24" LIBXML="2.7.8" LIBJSON="UNKNOWN" (core procs from "2.1.0beta2 r11441" need upgrade) TOPOLOGY (topology procs from "2.1.0SVN r11345" need upgrade) RASTER (raster procs from "2.1.0beta2 r11441" need upgrade) PostgreSQL 9.2.4, compiled by Visual C++ build 1600, 64-bit

Also doesn't crash on this other 64-bit I have lying around

POSTGIS="2.0.4SVN r11468" GEOS="3.3.8-CAPI-1.7.8" PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 1.9.2, released 2012/10/08" LIBXML="2.7.8" LIBJSON="UNKNOWN" (core procs from "2.0.3 r11132" need upgrade) RASTER (raster lib from "2.0.3 r11132" need upgrade) (raster procs from "2.0.3 r11132" need upgrade) PostgreSQL 9.2.4, compiled by Visual C++ build 1600, 64-bit

comment:3 Changed 6 years ago by robe

actually my 9.2 32-bit version doesn't crash either. I discovered that was because I was using my gcc 4.5 postgis compiled binaries with gcc 4.8.0 libstd++ dlls I was experimenting with so had a gcc mismatch. If I switch back to my 4.5.4 libstd++ it works fine.

That said: kafka can you please do a

SELECT version(); 

and return what that is to rule out gcc as difference

comment:4 Changed 6 years ago by kafka

Thank you fo quick response. My version is:

"PostgreSQL 9.1.9 on x86_64-unknown-linux-gnu, compiled by gcc-4.4.real (Debian 4.4.5-8) 4.4.5, 64-bit"

comment:5 Changed 6 years ago by Bborie Park

Tested on PG 9.2 and 9.1 with PostGIS 2.0.4dev r11536 and PostGIS 2.1.0 r11542 with no problems. This would be with the following config...

PostgreSQL 9.2.3 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.7.1, 64-b
it | POSTGIS="2.1.0beta3dev r11542" GEOS="3.4.0dev-CAPI-1.8.0 r3808" PROJ="Rel. 
4.8.0, 6 March 2012" GDAL="GDAL 1.11dev, released 2013/04/13" LIBXML="2.8.0" LIB
JSON="UNKNOWN" RASTER

What I do find interesting with the valgrind output is the call to OGRLIBKMLDriver's destructor, which isn't used or loaded in the rasterize function.

comment:6 Changed 6 years ago by kafka

Our postgis_full_version: "POSTGIS="2.0.3 r11128" GEOS="3.3.8-CAPI-1.7.8" PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 1.9.2, released 2012/10/08" LIBXML="2.7.8" LIBJSON="UNKNOWN" RASTER"

Wee will try to recompile with SVN.

comment:7 Changed 6 years ago by robe

kafka,

Unfortunately I don't think its an issue with PostGIS raster specifically. I think Bborie's suspicions about your libkml driver having an issue might be right.

I just tried on my windows install:

PostgreSQL 9.2.4, compiled by Visual C++ build 1600, 32-bit POSTGIS="2.0.3 r11132" GEOS="3.4.0dev-CAPI-1.8.0 r0" PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 1.10.0, released 2013/04/24" LIBXML="2.7.8" LIBJSON="UNKNOWN" RASTER

and it worked fine. The difference is that Bborie and I compile our own GDAL and I don't think either of us has LIBKMLDriver compiled in.

Bborie can correct me if I am wrong, but as I recall he said the ST_DumpAsPolygons is the only raster function that calls into OGR part of GDAL.

comment:8 Changed 6 years ago by Bborie Park

ST_DumpAsPolygon is the only part of PostGIS raster that loads any of the OGR formats. We do access the OGR API though.

Just to be sure, I recompiled my GDAL with everything turned on (including KML) and this query does not fail. This would be on both my Slackware64 and Fedora 18 VMs.

comment:9 Changed 6 years ago by kafka

Resolution: fixed
Status: newclosed

We recompiled OGR library without KML support and now it is OK. Thank zou for support.

Note: See TracTickets for help on using tickets.