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


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 rprinceley, 12 years ago

Resolution: fixed
Status: newclosed

Fixed in trunk (r24310).

comment:2 by Even Rouault, 12 years ago

Resolution: fixed
Status: closedreopened

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 Even Rouault, 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 warmerdam, 12 years ago

Cc: warmerdam 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 Even Rouault, 12 years ago

Frank, such a file aready exists in the autotest suite :


comment:6 by rprinceley, 12 years ago


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 Even Rouault, 12 years ago


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 rprinceley, 12 years ago


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 Jukka Rahkonen, 9 years ago

Kakadu is at 7.5 now. Has the GDAL trunk been updated with the fix by now?

comment:10 by Jukka Rahkonen, 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 Even Rouault, 8 years ago

Resolution: fixed
Status: reopenedclosed

The fix was pushed into trunk in r25136 3 years ago.

Note: See TracTickets for help on using tickets.