Opened 13 years ago
Closed 12 years ago
#1760 closed defect (fixed)
[raster] crash if gdal_data env variable not in place on windows 64
Reported by: | robe | Owned by: | pracine |
---|---|---|---|
Priority: | medium | Milestone: | PostGIS 2.0.1 |
Component: | raster | Version: | 2.0.x |
Keywords: | win64, mingw64, history | Cc: |
Description
I was doing a spatial query with ST_Clip and I neglected to put in the GDAL_DATA environment variable before hand.
The query crashed the service and logs show this:
ERROR 4: Unable to open EPSG support file gcs.csv. Try setting the GDAL_DATA environment variable to point to the directory containing EPSG csv files. 2012-04-07 08:03:57 EST LOG: server process (PID 3144) was terminated by exception 0xC0000005
After registering the variable things work fine — so might be one of those null character issues similar to what we had with null proj4text strings.
This is on a windows 2008 R2 64-bit running 64-bit PostgreSQL/PostGIS
Change History (5)
comment:1 by , 13 years ago
comment:2 by , 13 years ago
Milestone: | PostGIS 2.0.1 → PostGIS 2.0.2 |
---|---|
Summary: | crash if gdal_data env variable not in place on windows 64 → [raster] crash if gdal_data env variable not in place on windows 64 |
I don't think this is something we can readily resolve other than mentioning that GDAL_DATA may need to be set in the docs.
comment:3 by , 13 years ago
Can you try r9967 for 2.0? It may prevent the crash. I don't know why the crash is occurring as I just dug through the GDAL code that accesses gsc.csv and don't see any crashers.
comment:4 by , 13 years ago
I suspect its probably a similar thing to the issue we had a while back with windows crashing with empty string proj4texts. I'll give a try when I get up.
comment:5 by , 12 years ago
Keywords: | history added |
---|---|
Milestone: | PostGIS 2.0.2 → PostGIS 2.0.1 |
Resolution: | → fixed |
Status: | new → closed |
I can't get it to crash anymore on my 2.0.1 r9979 and the postgis_full_version() reads
POSTGIS="2.0.1 r9979" GEOS="3.4.0dev-CAPI-1.8.0 r0" PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 1.9.1, released 2012/05/15 GDAL_DATA not found" LIBXML="2.7.8" LIBJSON="UNKNOWN" RASTER
So I think you fixed in 2.0.1
Freaky. The error message is emitted by GDAL. I'll have to do some digging to see if we can check that GDAL is able to find its data and then throw an error if not able to do so.