Opened 12 years ago
Closed 8 years ago
#4638 closed defect (fixed)
JP2KAK driver crashes reading certain datasets using RasterIO()
Reported by: | rprinceley | Owned by: | rprinceley |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | GDAL_Raster | Version: | svn-trunk |
Severity: | normal | Keywords: | jp2kak |
Cc: | warmerdam |
Description
Encountered certain JP2 RGBA files with 16bit RGB and 8bit alpha bands. Using RasterIO() to read all bands in such a dataset will trigger a crash.
Ideally, JP2KAKRasterBand::IReadBlock() should skip bands that are not of the same data type when reading multiple bands.
Change History (11)
comment:1 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:2 by , 12 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
I'm a bit doubtfull that the fix is correct in all situations. The code skips bands that are not of the data type of the 'current' band, but after the DirectRasterIO() call, the loop that copies from the buffer to the block cache always assumes that anBands[i] == i + 1, which is no longer the case. So there's a risk that the block cache of one band is filled with data that does not come from another band.
This might be only a theoretical flaw, and I guess you probably didn't notice it, because in practice the alpha band is likely the last one and of different type, so the bug cannot be triggered.
comment:3 by , 12 years ago
Hum, actually, if you open the dataset and *immediately* do a RasterIO() only on the alpha band, I guess that you can trigger the bug.
comment:4 by , 12 years ago
Cc: | added |
---|
I would be interested in access (private would be ok) to a file triggering this problem to evaluate the fix and consider a more complete solution.
comment:5 by , 12 years ago
Frank, such a file aready exists in the autotest suite :
autotest/gdrivers/data/3_13bit_and_1bit.jp2
comment:6 by , 12 years ago
Frank,
The data we have is similar to this (16bit RGB + 1 alpha/mask), all appear to be created using the ECW SDK or ER Mapper.
comment:7 by , 12 years ago
Robin,
I see that you've pushed a fix in r24367 in the 1.8-esri branch (perhaps accidentally, since the commit message doesn't reflect that). Perhaps worth pushing it into trunk too ?
comment:8 by , 12 years ago
Even,
Yes, that was accidental. I will update trunk once the change is properly tested (we are in the middle of upgrading to Kakadu 7.0).
comment:9 by , 9 years ago
Kakadu is at 7.5 now. Has the GDAL trunk been updated with the fix by now?
comment:10 by , 8 years ago
Checking what is the situation now when Kakadu v. 7.7 has been released. Is the ticket still valid?
comment:11 by , 8 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
The fix was pushed into trunk in r25136 3 years ago.
Fixed in trunk (r24310).