Opened 11 years ago
Closed 11 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 , 11 years ago
| Component: | postgis → raster |
|---|---|
| Owner: | changed from to |
| Summary: | ST_DumpAsPolygons database engine crash → [raster]: ST_DumpAsPolygons database engine crash |
comment:2 by , 11 years ago
comment:3 by , 11 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 , 11 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 , 11 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 , 11 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 , 11 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 , 11 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 , 11 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
We recompiled OGR library without KML support and now it is OK. Thank zou for support.
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.
It however doesn't crash on my windows 9.2.4s. 64-bit installs
Also doesn't crash on this other 64-bit I have lying around