Opened 9 years ago

Closed 9 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 by robe, 9 years ago

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

comment:2 by robe, 9 years ago

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 by robe, 9 years ago

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 by kafka, 9 years ago

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 by Bborie Park, 9 years ago

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 by kafka, 9 years ago

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 by robe, 9 years ago

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 by Bborie Park, 9 years ago

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 by kafka, 9 years ago

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.