Gdalwarp 1.9.2 spontaneous appcrash

[sshak]

I have an image dataset that I'm reprojecting and retiling. I have successfully performed the same command on my set of input files before, but suddenly the command I'm running causes an appcrash. I've not been able to identify the root cause. I have tested my hardware and that passes, my file system passes, and I have updated gdal from 1.9.1 to 1.9.2 which has not fixed the problem.

The first step of my script is to reproject the data into my needed format from any source datum. I generate a commandline call to gdalwarp that looks like the following. gdalwarp -t_srs EPSG:4326 -wm 500 -srcnodata 0 -dstnodata 0 infile outfile This is crashing consistently on files it has successfully reprojected with the same command before. The appcrash data is as follows:

Problem signature:

Problem Event Name: APPCRASH Application Name: gdalwarp.exe Application Version: 0.0.0.0 Application Timestamp: 5129e7fd Fault Module Name: libecwj2.dll Fault Module Version: 0.0.0.0 Fault Module Timestamp: 4cc459ff Exception Code: c0000005 Exception Offset: 0000000000089947 OS Version: 6.1.7601.2.1.0.256.48 Locale ID: 1033 Additional Information 1: 0980 Additional Information 2: 098019b1ed8ab0ef4d9368e03d259ac9 Additional Information 3: df0e Additional Information 4: df0ef3e130a4fe176d8cc013920217e4

Getting the stack trace shows: <lines for exception handler/dispatcher> libecwj2.dll!CNCSJPCPrecinct::ReadPackets+0x137 libecwj2.dll!CNCSJPCPrecinct::CreateSubBands+0xb4 libecwj2.dll!CNCSJPCPrecinct::ReadLine+0x33 libecwj2.dll!CNCSJPCResolution::ReadSubBandLine+0x5b2 libecwj2.dll!CNCSJPCResolution::INTERLEAVE_2D+0x93f libecwj2.dll!CNCSJPCResolution::HOR_SR+0xde libecwj2.dll!CNCSJPCResolution::GET_STATE_BUFFER+0x196 libecwj2.dll!CNCSJPCResolution::VER_SR_INPUT2+0x20e libecwj2.dll!CNCSJPCResolution::VER_SR+0x80e libecwj2.dll!CNCSJPCResolution::SR_2D+0x134 libecwj2.dll!CNCSJPCResolution::ReadLine+0x236 libecwj2.dll!CNCSJPCNode::ReadLine+0x6a libecwj2.dll!CNCSJPCComponent::ReadLine+0x84 libecwj2.dll!CNCSJPCNode::ReadLine+0x6a libecwj2.dll!CNCSJPCDCShiftNode::ReadLine+0x85 libecwj2.dll!CNCSJPCNode::ReadLine+0x6a libecwj2.dll!CNCSJPCNodeTiler::ReadLine+0x34c libecwj2.dll!CNCSJPCResample::ReadLine+0x1b8 libecwj2.dll!CNCSJP2FileView::ReadLineBIL+0x3de libecwj2.dll!CNCSJP2FileView::ReadLineBIL+0x15f gdal_ECW_JP2ECW.dll!ECWDataset::IRasterIO+0x4c7 gdal19.dll!GDALDataset::RasterIO+0x499 gdal19.dll!GDALDatasetRasterIO+0xc0 gdal19.dll!GDALWarpOperation::WarpRegionToBuffer+0x2f5 gdal19.dll!GDALWarpOperation::WarpRegion+0x4bc gdal19.dll!GDALWarpOperation::ChunkAndWarpImage+0x155 gdalwarp.exe!OGRCoordinateTransformation::OGRCoordinateTransformation+0x3755 gdalwarp.exe!std::basic_string<char,std::char_traits<char>,std::allocator<char> >::operator=+0x99e kernel32.dllBaseThreadInitThunk+0xd ntdll.dllRtlUserThreadStart+0x21

This is a windows 7 64bit system and I have the following files installed. python 2.7 64bit. gdal-19-1600-x64-core.msi gdal-19-1600-x64-ecw.msi gdal-19-1600-x64-mrsid.msi GDAL-1.9.2.win-amd64.py2.7.msi These are the VS2010 stable builds listed as built 2/24/2013 from the release-1600-x64-gdal-1-9-mapserver-6-2 page.

[Even Rouault]

Hum, this seems to be more an issue with the ECW or JP2 dataset that must (I guess) be the source dataset of gdalwarp. Could you try : "gdalinfo -checksum thesourcedataset" ? if this crashes, then it is likely an issue in the ECW SDK. Providing the file or a link to it might help confirming this.

[sshak]

I ran the command as you requested and it also caused the crash. I am not certain that the datafile itself is corrupt and causing the issue since I can use the image without issues in other software (global mapper, arcmap) and the gdal utilities have successfully processed this file before on the same computer. There were no changes that I know of before the issue happened unless windows had some update that posted and has corrupted the functionality of the library. This is making it more difficult to pinpoint.

I would upload the file, but it is too large to attach to the ticket and I don't have a simple location for hosting the file. I will look into an alternative means to provide the file, but in the mean time are there other steps you can recommend to assist in finding the cause/solution to the issue?

[Even Rouault]

There are known issues with the ECW SDK 3.3 that are hit sometimes even with valid files. Another option would be that you would build GDAL from source with a more recent ECW SDK (4.3).

Perhaps an easier approach would be to use another build from gisinternals, possibly a 32-bit build instead of a 64bit build, or a build with another version of MSVC

[sshak]

Thanks for the support. Getting the build of ECW working will be something I'll have to look into and is more there for future support. Since I'm working on JP2 and SID files for the moment, I am just going to remove the ECW lib and let the internal OpenJpeg2000 library or SID library take over for JP2. Should the base GDAL consider better which version of JP2 support to load if the ECW 3.3 support is known as flawed or are there plans to update the ECW plugin installer to 4.3?

Since this workaround is working for me I'm marking this as closed.