GDAL crash in ERDAS NCSEcw4_RO.dll used through Python interface

[bcarpenter]

Unfortunately, I don't currently have the ability to pull together a test case to accompany this ticket that would reliably demonstrate the problem. My guess is that there's a "wild C pointer" problem, so even the Windows error dialog that implicates the NCSEcw4_RO.dll file could be a "red herring." When we experience the problem, the image we are examining is a .vrt file that is based on another .vrt file based on a NITF (.ntf) file. So I don't think there's even a reason for the NCSEcw4_RO.dll file that comes from the "ERDAS ECW/JP2 SDK" to be in the picture.

The calls we make from the Python api are:

dataset = gdal.Open()
band = dataset.GetRasterBand()
band.SetNoDataValue()
band.GetStatistics()

and possibly band.GetHistogram(), but I don't think it gets that far.

Here are the dialogs that Windows puts up when the crash happens: I have attached the file WER0a04.dir00.zip holding the files that the above dialog refers to.

The version we are using is from the OSGeo4W Setup program and what I recall is that it was just "1.9.1-RC2" at the time, but now I see that the Setup program offers "1.9.1-RC2-2" and "1.9.1-RC2-1" I believe that what we are using is what is now called the "-1" version.

[bcarpenter]

Image showing the Windows crash dialogs.

[bcarpenter]

It turns out that the 52 Megabyte "WER0a04.dir00.zip" file I said I'd attach was way past the size limit for Trac. But I will keep that information available so I can supply it later if needed.

[Even Rouault]

If the NITF file is JPEG2000 compressed, then the mention to NCSEcw4_RO.dll is not impossible. What happens if you try : "gdalinfo -stats thefile.ntf" ? Did you use the right version of the ECW SDK too (see ​http://trac.osgeo.org/osgeo4w/wiki/pkg-gdal-ecw) ?

[Even Rouault]

No feedback from reporter. Closing. Reopen if you can provide more information