Opened 13 years ago

Closed 11 years ago

#4201 closed defect (fixed)

JP2 crash using ECW driver

Reported by: timlinux Owned by: warmerdam
Priority: normal Milestone: 1.10.0
Component: default Version: 1.8.0
Severity: normal Keywords: jp2 ecw crash
Cc: wluck@…

Description

We consistently have crashes with JP2 imagery that has been created in PCI (with tiling enabled) when trying to open them with the ECW JP2 driver. Backtrace follows:

(gdb) run /home/gisdata/FUNDISA/CSIR_SAC_FUNDISA_2009/Imagery/Spot5_2008/TLJP2/3425B.jp2
Starting program: /usr/local/bin/gdalinfo /home/gisdata/FUNDISA/CSIR_SAC_FUNDISA_2009/Imagery/Spot5_2008/TLJP2/3425B.jp2
[Thread debugging using libthread_db enabled]
[New Thread 0x7fffee2fe700 (LWP 9984)]
[New Thread 0x7fffedafd700 (LWP 9985)]
[New Thread 0x7fffed2fc700 (LWP 9986)]
[New Thread 0x7fffecafb700 (LWP 9987)]

Program received signal SIGSEGV, Segmentation fault.
CNCSJPCTilePartHeader::GetNrPackets (this=0x0) at ../C/NCSEcw/NCSJP2/NCSJPCTilePartHeader.cpp:753
753		if(!m_NrPackets.Cached()) {
(gdb) bt
#0  CNCSJPCTilePartHeader::GetNrPackets (this=0x0) at ../C/NCSEcw/NCSJP2/NCSJPCTilePartHeader.cpp:753
#1  0x00007ffff5644b3b in CNCSJPCTilePartHeader::GetFirstPacketNr (this=0x7fffe98f74c0) at ../C/NCSEcw/NCSJP2/NCSJPCTilePartHeader.cpp:744
#2  0x00007ffff5627577 in CNCSJPCProgression::Start (this=0x7fffe98f7530, pMainTP=0x7fffe98f74c0, nComponent=<value optimized out>, nResolution=<value optimized out>)
    at ../C/NCSEcw/NCSJP2/NCSJPCProgression.cpp:107
#3  0x00007ffff562609c in CNCSJPCProgression::Start (this=0x7fffe98f7530, pMainTP=0x7fffe98f74c0) at ../C/NCSEcw/NCSJP2/NCSJPCProgression.cpp:100
#4  0x00007ffff5645d7f in CNCSJPCTilePartHeader::Parse (this=0x7fffe98f74c0, JPC=..., Stream=...) at ../C/NCSEcw/NCSJP2/NCSJPCTilePartHeader.cpp:297
#5  0x00007ffff5614090 in CNCSJPCMainHeader::Parse (this=0x7fffe8001f00, JPC=..., Stream=...) at ../C/NCSEcw/NCSJP2/NCSJPCMainHeader.cpp:201
#6  0x00007ffff56059dd in CNCSJPC::Parse (this=0x7fffe8001f00, Stream=...) at ../C/NCSEcw/NCSJP2/NCSJPC.cpp:65
#7  0x00007ffff55d80fd in CNCSJP2File::CNCSJP2ContiguousCodestreamBox::Parse (this=0x7fffe8001e98, JP2File=<value optimized out>, Stream=...) at ../C/NCSEcw/NCSJP2/NCSJP2ContiguousCodestreamBox.cpp:48
#8  0x00007ffff5603f48 in CNCSJP2SuperBox::Parse (this=0x7fffe8001690, JP2File=..., Stream=...) at ../C/NCSEcw/NCSJP2/NCSJP2SuperBox.cpp:108
#9  0x00007ffff55daaa3 in CNCSJP2File::Open (this=0x7fffe8001690, Stream=...) at ../C/NCSEcw/NCSJP2/NCSJP2File.cpp:261
#10 0x00007ffff55d8e40 in CNCSJP2File::Open (this=0x7fffe8001690, pName=0x7fffffff3a90 L"/home/gisdata/FUNDISA/CSIR_SAC_FUNDISA_2009/Imagery/Spot5_2008/TLJP2/3425B.jp2", bWrite=<value optimized out>)
    at ../C/NCSEcw/NCSJP2/NCSJP2File.cpp:200
#11 0x00007ffff55da8d6 in CNCSJP2File::sOpen (ppFile=0x7fffe80011b0, pURLPath=0x7fffffff3a90 L"/home/gisdata/FUNDISA/CSIR_SAC_FUNDISA_2009/Imagery/Spot5_2008/TLJP2/3425B.jp2")
    at ../C/NCSEcw/NCSJP2/NCSJP2File.cpp:797
#12 0x00007ffff55ed160 in CNCSJP2FileView::Open (this=0x7fffe80010b0, pURLPath=0x620f28 "/home/gisdata/FUNDISA/CSIR_SAC_FUNDISA_2009/Imagery/Spot5_2008/TLJP2/3425B.jp2", bProgressiveDisplay=false, 
    bWrite=<value optimized out>) at ../C/NCSEcw/NCSJP2/NCSJP2FileView.cpp:237
#13 0x00007ffff7083f4b in ECWDataset::OpenFileView(char const*, bool, int&) () from /usr/local/lib/libgdal.so
#14 0x00007ffff708442b in ECWDataset::Open(GDALOpenInfo*, int) () from /usr/local/lib/libgdal.so
#15 0x00007ffff7083dc3 in ECWDataset::OpenJPEG2000(GDALOpenInfo*) () from /usr/local/lib/libgdal.so
#16 0x00007ffff73467c4 in GDALOpenInternal(GDALOpenInfo&, char const* const*) () from /usr/local/lib/libgdal.so
#17 0x00007ffff734669d in GDALOpenInternal(char const*, GDALAccess, char const* const*) () from /usr/local/lib/libgdal.so
#18 0x00007ffff734665c in GDALOpen () from /usr/local/lib/libgdal.so
#19 0x0000000000402915 in main (argc=2, argv=0x622a70) at gdalinfo.c:170
(gdb) 

I appreciate that the actual crash seems to be happening down in ECW code rather than in GDAL per se', but perhaps there is something GDAL can do to exit gracefully from this? The problem is that the problem propogates itself up to QGIS (e.g. windows build downloaded via OSGEO4W) which crashes when the file is opened.

Other Jp2 files open fine e.g. the samples that come with the GeoSDK, and others like this one: ftp://ftp.microimages.com/pub/tnt/data/jp2/gtopo30lossless.zip also fine. So it seems to be specific to certain images.

For the record I can replicate the issue on linux using Geo_DSDK-7.0.0.2167.

Change History (5)

comment:1 by Even Rouault, 13 years ago

Do you have a link to one of those images that cause this issue ? But I'm not sure what GDAL could do to prevent crashes in third-party code.

One possibility would be to "fix" (avoiding the crash at least) the faulty code in the old 3.3 SDK whose source code is available (should be doable, looks like a null pointer dereference), but that leaves the issue still opened for the closed source 4.X SDK. So the best would be to report to the vendor(s) of the SDK(s) and hope they fix it properly.

A workaround for QGIS would be, once the dataset has been identified as being JP2, to fork a helper process that basically does a GDALOpen() and if it doesn't crash (actually, you would install a Structured Exception Handling handler on Windows to avoid the Windows pop-up that is triggered by a process crash) and returns some value indicating success, you can proceed to GDALOpen() in the QGIS process...

in reply to:  1 comment:2 by timlinux, 13 years ago

Replying to rouault:

Do you have a link to one of those images that cause this issue ? But I'm not sure what GDAL could do to prevent crashes in third-party code.

I'm trying to get some test images created (the ones where we experienced the problem are SPOT image data and can't be put on a public site. I'll update this ticket with a link to the test images when they are available.

One possibility would be to "fix" (avoiding the crash at least) the faulty code in the old 3.3 SDK whose source code is available (should be doable, looks like a null pointer dereference), but that leaves the issue still opened for the closed source 4.X SDK. So the best would be to report to the vendor(s) of the SDK(s) and hope they fix it properly.

Yes an upstream fix with updated osgeo4w ecw libs would be the ideal result. I'll look into the procedure for filing a ticket with ERDAS.

A workaround for QGIS would be, once the dataset has been identified as being JP2, to fork a helper process that basically does a GDALOpen() and if it doesn't crash (actually, you would install a Structured Exception Handling handler on Windows to avoid the Windows pop-up that is triggered by a process crash) and returns some value indicating success, you can proceed to GDALOpen() in the QGIS process...

Ok, interesting - I'll take a look at implementing that, thanks.

Regards

Tim

comment:3 by csbruce, 12 years ago

I've just experienced this segfault problem, too, with gdal-1.9.0 and a patched libecwj2-3.3. My solution is simply to comment out the call to GDALRegister_JP2ECW() in "gdalallregister.cpp" and use the OpenJpeg .jp2 driver instead. It seems to me that JP2ECW should have lower precedence than the other JPEG2000 drivers since the library is either proprietary (4.1) or very old (3.3), plus, the user must specifically install one of these other JPEG2000 drivers, indicating that they truly want to use it. I only want to use the ECW library to read ECW format.

comment:4 by Even Rouault, 12 years ago

You don't need to recompile GDAL. You can define the GDAL_SKIP=JP2ECW environment variable so that the JP2ECW driver isn't used.

The order of drivers is somewhat arbitrary, but the current order has some rationale too. We cannot deny that the JP2ECW driver is way faster than the open source alternatives, so if people bothered to compile GDAL with ECW SDK support, it is likely they want it to be used for both JP2 or ECW. But one could argue for hours on the order ;-)

comment:5 by Even Rouault, 11 years ago

Milestone: 1.10.0
Resolution: fixed
Status: newclosed

The GDAL_API_PROXY mechanism added per http://trac.osgeo.org/gdal/ticket/4979 can be used to avoid crashes in the ECW SDK to prepagate to the caller of the GDAL API

Note: See TracTickets for help on using tickets.