JDK-4776610 : PIT:REG: Exception when converting some PNG images to BufferedImage.TYPE_INT_ARG
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.4.2
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_8
  • CPU: sparc
  • Submitted: 2002-11-10
  • Updated: 2002-11-12
  • Resolved: 2002-11-12
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.2 mantisFixed
Related Reports
Relates :  
Description
For some image files of type PNG, when they are converted to BufferedImage.TYPE_INT_ARGB, a java.lang.ArrayIndexOutOfBoundsException exception is thrown.

This bug was introduced with Java2D PIT "Build:08-Nov-02@02:50.mantis".  The failure does not occur with last promoted Mantis build 1.4.2-beta-b06.

The bug occurs on Solaris and Win2000 platforms.  The failure has (so far) not been reproducable with JPG image files.

A test application "BufferedImageTest.java" is attached to reproduce the failure.  The application will read an image file and then go through converting the image to all supported BufferedImage types.  See sample output below.

Steps to reproduce:
------------------
java BufferedImageTest <file name, otherwise defaults to shade.png>

1) java BufferedImageTest cup.png
Testing with image: cup.png  (test passes with this PNG file)

2) java BufferedImageTest shade.png
Testing with image: shade.png
Fail with BufferedImage Type: BufferedImage.TYPE_INT_ARGB java.lang.ArrayIndexOutOfBoundsException: Coordinate out of bounds!
java.lang.ArrayIndexOutOfBoundsException: Coordinate out of bounds!
        at sun.awt.image.ShortInterleavedRaster.getDataElements(ShortInterleavedRaster.java:221)
        at sun.java2d.loops.OpaqueCopyAnyToArgb.Blit(CustomComponent.java:104)
        at sun.java2d.pipe.DrawImage.blitSurfaceData(DrawImage.java:621)
        at sun.java2d.pipe.DrawImage.renderSurfaceData(DrawImage.java:346)
        at sun.java2d.pipe.DrawImage.copyImage(DrawImage.java:66)
        at sun.java2d.pipe.DrawImage.copyImage(DrawImage.java:50)
        at sun.java2d.pipe.DrawImage.copyImage(DrawImage.java:717)
        at sun.java2d.SunGraphics2D.drawImage(SunGraphics2D.java:2755)
        at sun.awt.image.ImageRepresentation.drawToBufImage(ImageRepresentation.java:726)
        at sun.java2d.pipe.DrawImage.copyImage(DrawImage.java:724)
        at sun.java2d.pipe.ValidatePipe.copyImage(ValidatePipe.java:147)
        at sun.java2d.SunGraphics2D.drawImage(SunGraphics2D.java:2755)
        at sun.java2d.SunGraphics2D.drawImage(SunGraphics2D.java:2745)
        at BufferedImageTest.test(BufferedImageTest.java:61)
        at BufferedImageTest.main(BufferedImageTest.java:77)

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis FIXED IN: mantis INTEGRATED IN: mantis mantis-b07
14-06-2004

EVALUATION The Blit methods in CustomComponent.java are not properly intersecting all the bounds involved (requested bounds, source and destination bounds, etc), which results in the inner loops attempting to access/modify pixels out of the surface bounds. This clipping work used to be handled by the DrawImage.clipAndRenderSurfaceData() method, but the Blit implementations now do their own lower-level Region-based clipping. Apparently these Java-level Blit implementations (OpaqueCopyAnyToArgb, etc) were not properly updated. The fix is to add the appropriate blit bounds intersection code to these Blit methods to prevent the inner loop from accessing invalid (out of bounds) pixels. See Blit.c for the general approach. ###@###.### 2002-11-09 The problem described here was actually caused by the recent fix for 4775930. That fix updated the RegionSpanIterator.nextSpan() method so that it would return one span (representing the Region's bounds) if the associated Region is rectangular. Unfortunately the fix was slightly incorrect; the returned span should represent the "path box" of the RegionSpanIterator, not the full Region bounds. The path box is essentially the Region's bounds (possibly) clipped to some region of interest using RSI.intersectClipBox(). The CustomComponent Blit methods establish this region of interest, representing the destination blit bounding box, when they call clip.getSpanIterator(box). This limits the scope of the SpanIterator to the intersection of "box" and the Region's bounds. The fix is very similar to that of 4775930; detect when the Region is rectangular, and if it is, make sure we return one span from nextSpan(). The only change is that we will now return the RSI's path box (fetched via getPathBox()) rather than returning the Region's bounds. Before this fix, the span returned to the CustomComponent Blit methods would not be clipped to the desired destination blit bounds (dstx, dsty, dstx+w, dsty+h). With this fix in place, the single span correctly represents the intersection of the destination blit bounds and the surface's rectangular clip Region. ###@###.### 2002-11-09
09-11-2002