From jayathirth.d.v at oracle.com Tue Jan 2 06:53:20 2018 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 1 Jan 2018 22:53:20 -0800 (PST) Subject: [OpenJDK 2D-Dev] [11] RFR: [JDK-5064835] TextMeasurer/deleteChar function fails when deleting more than one characters In-Reply-To: <4c4a1107-5c91-4307-a467-715ea8ca992c@default> References: <4c4a1107-5c91-4307-a467-715ea8ca992c@default> Message-ID: Hi Prahalad, Please find my inputs: Since we are making changes to deleteChar() code and specification I think we should make similar changes to insertChar() to make them behave in same way. I observed Jane Wang comment in JBS and tested inserting multiple character using TextMeasurer.insertChar() and it doesn't through ArrayIndexOutOfBoundsException or any other exception, it just initializes the text parameters using the newParagraph. We can make changes corresponding to insertChar() in the same bug or we can raise separate bug, but its better if we make changes to insertChar() also in the same JBS as they are similar change corresponding to identical behavior in same Class. Regarding JCK test fail, since we are targeting it to JDK 11 I think we have time to update the same without any risk. But we should get input from Phil/Others regarding the same. In the test case may be we can remove the System.out.println("Test passed."), since we know that if we don't get any exception/errors the jtreg test is passed. I see that some test cases have this "Test Passed" output but I feel it is redundant. Thanks, Jay -----Original Message----- From: Prahalad Kumar Narayanan Sent: Friday, December 29, 2017 4:30 PM To: 2d-dev Subject: [OpenJDK 2D-Dev] [11] RFR: [JDK-5064835] TextMeasurer/deleteChar function fails when deleting more than one characters Hello Everyone Good day to you. Request your time in reviewing the fix for the bug: JDK-5064835 TextMeasurer/deleteChar function fails when deleting more than one characters. Root Cause: . The spec clearly mentions that the concerned method is to be used to delete a single character. . However, the spec does not mention the outcome when the method is used to delete multiple characters (as reported in the bug) Solution Approaches: . Since the spec does not mention the outcome when multiple characters are deleted, the result is left to the implementation. . The solution can be approached in two perspectives- 1. Update the spec to explicitly mention the exception that would be thrown in such cases or 2. Re-initialize the TextMeasurer with the new text as present in the argument of the method. Solution: . I inspected feasibility/ risk of both the approaches and I 'm of the opinion that approach 1. is better. . Reason is that, with the second approach- . The re-initialization would reset all text attributes, and state variabes that were set on TextMeasurer (and internal StyledParagraph) object. . If re-initialization is required, one could create a new TextMeasurer using the modified text rather than invoking deleteChar method. . Thus in the proposed solution- I 've added a throws clause that explicitly mentions that IllegalArgumentException will be thrown when attempted to delete multiple characters. Other Info: . The fix was tested with existing jtreg test cases- No regressions were seen. . 2 JCK tests have been found to fail. They are- . java_awt/Font/TextMeasurer/CharTest (TestCase5) . java_awt/Font/LineBreakMeasurer/CharTest (TestCase4) . In both the failures, incorrect arguments are passed to deleteChar method- newParagraph (with multiple chars deleted) & beginIndex (-1) . While the test case expects index out of bounds exception for -ve index, the code now throws IllegalArgumentsException. . A minor correction to JCK test will fix the issue. I shall raise a JCK bug once the fix is approved & submitted. Kindly review the changes at your convenience & share your feedback: http://cr.openjdk.java.net/~pnarayanan/5064835/webrev.00/ Note: I 've not raised a CSR for this bug yet. Based on review, I will create the CSR for change to the specification. Thank you for your time in review & Happy New Year Prahalad N. From jayathirth.d.v at oracle.com Thu Jan 4 07:06:59 2018 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Wed, 3 Jan 2018 23:06:59 -0800 (PST) Subject: [OpenJDK 2D-Dev] [11] RFR JDK-8191073: JpegImageReader throws IndexOutOfBoundsException when trying to read image data from tables-only image Message-ID: <08c8a3eb-7a09-443e-b14b-689abbecf9fb@default> Hello All, Please review the following fix in JDK11 : Bug : https://bugs.openjdk.java.net/browse/JDK-8191073 Webrev : http://cr.openjdk.java.net/~jdv/8191073/webrev.00/ Issue: When we try to read image data from JPEG input stream having tables-only information JPEGImageReader throws IndexOutOfBoundsException. Exception in thread "main" java.lang.IndexOutOfBoundsException: Index -1 out-of-bounds for length 0 at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64) at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70) at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:248) at java.base/java.util.Objects.checkIndex(Objects.java:372) at java.base/java.util.ArrayList.get(ArrayList.java:440) at java.desktop/com.sun.imageio.plugins.jpeg.JPEGImageReader.checkTablesOnly(JPEGImageReader.java:378) at java.desktop/com.sun.imageio.plugins.jpeg.JPEGImageReader.gotoImage(JPEGImageReader.java:493) at java.desktop/com.sun.imageio.plugins.jpeg.JPEGImageReader.readHeader(JPEGImageReader.java:716) at java.desktop/com.sun.imageio.plugins.jpeg.JPEGImageReader.readInternal(JPEGImageReader.java:1173) at java.desktop/com.sun.imageio.plugins.jpeg.JPEGImageReader.read(JPEGImageReader.java:1153) at java.desktop/javax.imageio.ImageIO.read(ImageIO.java:1468) at java.desktop/javax.imageio.ImageIO.read(ImageIO.java:1363) at JpegReaderOOBIssue.main(JpegReaderOOBIssue.java:25) Root cause: readNativeHeader() function returns the first header as tables-only image in checkTablesOnly() function. Because of this we don't update the start of this stream position as one of the imagePositions. After that in checkTablesOnly() we try to find any image data after stream metadata using hasNextImage() and it also returns false. So we have a input stream which contains only streamMetadata(tables-only image). In the same checkTablesOnly() we try to get initial imagePosition for this input stream in seekForwardOnly case. But since it is empty and we try "imagePositions.get(imagePositions.size()-1)" it throws IndexOutOfBoundsException. Solution: We should make changes at 2 places to fix this issue : 1) In checkTablesOnly() function if seekForward flag is enabled and the input stream is just tables-only we should not try to access imagePositions variable as it will be empty. imagePositions list is in 1:1 relationship with number on image indices available in given input stream. 2) In checkTablesOnly() function when we get to know that the given input stream is just tables only image we should maintain that state in a boolean variable like "tablesOnlyStream" so that if we try to access image information in gotoImage() we should throw an IIOException mentioning that there is no image data available. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From prahalad.kumar.narayanan at oracle.com Fri Jan 5 05:30:56 2018 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Thu, 4 Jan 2018 21:30:56 -0800 (PST) Subject: [OpenJDK 2D-Dev] [11] RFR: [JDK-8194489] Incorrect size computation at BandedSampleModel.createDataBuffer Message-ID: <516bdf7d-337a-4968-9320-2cd1f4e32b3d@default> Hello Everyone Good day to you. Request your time to review the fix for the bug: JDK-8194489 Incorrect size computation at BandedSampleModel . createDataBuffer Root Cause: . The method BandedSampleModel . createDataBuffer does not consider number of banks and band offsets while computing the required memory size. . As a result, ArrayIndexOutOfBounds exception is thrown when setting pixel values on banded sample models having - . Multiple bands of image data stored in multiple banks of DataBuffer with band offsets . Multiple bands of image data stored in single bank of DataBuffer Solution: . Appropriate logic has been added to createDataBuffer method. Other Info: . All Jtreg test-cases in java/awt/image were run with the build including the fix. . No regressions were noticed. Kindly review the changes at your convenience & share your feedback. Link: http://cr.openjdk.java.net/~pnarayanan/8194489/webrev.00/ Thank you for your time in review Have a good day Prahalad N. From brian.burkhalter at oracle.com Fri Jan 5 22:51:46 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 5 Jan 2018 14:51:46 -0800 Subject: [OpenJDK 2D-Dev] [11] RFR: [JDK-8194489] Incorrect size computation at BandedSampleModel.createDataBuffer In-Reply-To: <516bdf7d-337a-4968-9320-2cd1f4e32b3d@default> References: <516bdf7d-337a-4968-9320-2cd1f4e32b3d@default> Message-ID: <8A71DE42-66E1-4CC7-A0B9-FFA71F021A1F@oracle.com> Hello Prahalad, On Jan 4, 2018, at 9:30 PM, Prahalad Kumar Narayanan wrote: > Request your time to review the fix for the bug: > JDK-8194489 Incorrect size computation at BandedSampleModel . createDataBuffer https://bugs.openjdk.java.net/browse/JDK-8194489 > Kindly review the changes at your convenience & share your feedback. > Link: http://cr.openjdk.java.net/~pnarayanan/8194489/webrev.00/ In general I think this looks good. A few comments: BandedSampleModel L193-196 and 203-207: In general I think it?s better for method-internal comments to use the ?//? form instead of the ?/*?*/? form. BandedSampleModelSizeTest Instead of defining the utility methods compareSamples(int[],int[]) and initSamples(int[],int) you might consider simply using j.u.Arrays.equals(int[],int[]) and j.u.Arrays.fill(int[],int), respectively. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Fri Jan 5 23:13:12 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 5 Jan 2018 15:13:12 -0800 Subject: [OpenJDK 2D-Dev] [11] RFR JDK-8191073: JpegImageReader throws IndexOutOfBoundsException when trying to read image data from tables-only image In-Reply-To: <08c8a3eb-7a09-443e-b14b-689abbecf9fb@default> References: <08c8a3eb-7a09-443e-b14b-689abbecf9fb@default> Message-ID: <21595BF6-0BAF-476A-90C2-B094354E65E3@oracle.com> Hi Jay, On Jan 3, 2018, at 11:06 PM, Jayathirth D V wrote: > Bug : https://bugs.openjdk.java.net/browse/JDK-8191073 > Webrev : http://cr.openjdk.java.net/~jdv/8191073/webrev.00/ General comment: I think it?s better to use ?//? than ?/*?*/? for method-internal comments: JpegImageReader L373-375, 392-397, 516-519 JpegTablesOnlyReadTest L61-64 As to the fix, is the new tablesOnlyStream boolean really necessary? For example at line 520 in the new version could not one do this if (imagePositions.isEmpty()) { // line 520 of new version throw new IIOException("No image data present to read"); } instead? I don?t see where the value of this variable is used anywhere else. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Sat Jan 6 08:42:51 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sat, 6 Jan 2018 00:42:51 -0800 Subject: [OpenJDK 2D-Dev] [11] RFR: [JDK-8194489] Incorrect size computation at BandedSampleModel.createDataBuffer In-Reply-To: <516bdf7d-337a-4968-9320-2cd1f4e32b3d@default> References: <516bdf7d-337a-4968-9320-2cd1f4e32b3d@default> Message-ID: Hi, Prahalad. Not an expert here, but have a small question about implementation of this method in the parent class(ComponentSampleModel). Currently the parent class has a similar implementation of createDataBuffer(), but instead of "scanlineStride * height" it uses "getBufferSize()". And this "getBufferSize" has a number of additional checks, should not we do something similar here as well(see JDK-7058602)? On 04/01/2018 21:30, Prahalad Kumar Narayanan wrote: > Request your time to review the fix for the bug: > JDK-8194489 Incorrect size computation at BandedSampleModel . createDataBuffer > > Root Cause: > . The method BandedSampleModel . createDataBuffer does not consider number of banks and band offsets while computing the required memory size. > . As a result, ArrayIndexOutOfBounds exception is thrown when setting pixel values on banded sample models having - > . Multiple bands of image data stored in multiple banks of DataBuffer with band offsets > . Multiple bands of image data stored in single bank of DataBuffer > > Solution: > . Appropriate logic has been added to createDataBuffer method. > > Other Info: > . All Jtreg test-cases in java/awt/image were run with the build including the fix. > . No regressions were noticed. > > Kindly review the changes at your convenience & share your feedback. > Link: http://cr.openjdk.java.net/~pnarayanan/8194489/webrev.00/ > > Thank you for your time in review > Have a good day > > Prahalad N. > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Sat Jan 6 09:14:57 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sat, 6 Jan 2018 01:14:57 -0800 Subject: [OpenJDK 2D-Dev] RFR JDK-8191174: PngReader throws IllegalArgumentException because ScanlineStride calculation logic is not proper In-Reply-To: <74518345-8ed6-44da-b384-01802c01368c@default> References: <6639d1ae-fa52-4505-af5f-1bf3e114fbe5@default> <4903dfdb-8c64-4a38-95e2-549f26b3ee41@default> <045c7f01-106f-4f01-a661-a82ab15c1b1c@default> <74518345-8ed6-44da-b384-01802c01368c@default> Message-ID: Probably we can use Math.multiplyExact()? The current exception text wrapped a few times "Pixel stride times width must be less than or equal to the scanline stride" is not strictly correct because it is possible that the image itself has correct data, but we cannot handle it because of overflow. On 28/12/2017 22:49, Prahalad Kumar Narayanan wrote: > Hello Jay > > Good day to you. > > The code changes wrap the IllegalArgumentException in IIOException. > This approach is better & aligns with how OutOfMemoryError was wrapped to fix JDK-8190332. > > The only point that I 'm not sure is- whether we could wrap IllegalArgumentException twice before throwing to the user code. > > javax.imageio.IIOException: Error reading PNG image data > at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.readImage > at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.read > at java.desktop/javax.imageio.ImageIO.read > ... > Caused by: javax.imageio.IIOException: Caught exception during read: > at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.decodePass > at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.decodeImage > ... > Caused by: java.lang.IllegalArgumentException: Pixel stride times width must be less than or equal to the scanline stride > at java.desktop/java.awt.image.PixelInterleavedSampleModel. > at java.desktop/java.awt.image.Raster.createInterleavedRaster > at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.createRaster > > Since there are multiple levels of same exception, programmer could have trouble getting the cause using getCause() method. > However, Invoking printStackTrace() on the outer most exception object gives complete call stack (as listed above). > So I think, this should be ok. > > I would like to know of others' opinion too. > > Thank you > Have a good day > > Prahalad N. > > > -----Original Message----- > From: Jayathirth D V > Sent: Thursday, December 28, 2017 3:43 PM > To: Prahalad Kumar Narayanan; 2d-dev > Subject: RE: [OpenJDK 2D-Dev] RFR JDK-8191174: PngReader throws IllegalArgumentException because ScanlineStride calculation logic is not proper > > Hi Prahalad, > > Thanks for your valuable inputs. > > Even though the fix resolves the issue for the particular test case we have it will not solve the buffer overflow problem as you have mentioned in highest limit case or many other cases where the computed value is very high. > > Also we cannot change datatype of bytesPerRow/eltsPerRow as they are used in many passed to many other Raster and Stream API's. The best approach to resolve this issue would be to wrap the Exception that we are getting while creating Raster/SampleModel into an IIOException as we have done in https://bugs.openjdk.java.net/browse/JDK-8190332 . By doing this we will abide by specification and also we will have complete stack of why we got the exception so that it can be debugged properly in future. > > Please find updated webrev for review: > http://cr.openjdk.java.net/~jdv/8191174/webrev.01/ > > Thanks, > Jay > > -----Original Message----- > From: Prahalad Kumar Narayanan > Sent: Tuesday, December 19, 2017 3:08 PM > To: Jayathirth D V; 2d-dev > Subject: RE: [OpenJDK 2D-Dev] RFR JDK-8191174: PngReader throws IllegalArgumentException because ScanlineStride calculation logic is not proper > > > Hello Jay > > Good day to you. > > I don't think it's possible to fix this issue despite having intermediate " long " variable to hold intermediate bits per pixel. > Here is a simple math that considers the worst case scenario with max values: > > . As per the PNG specification, the maximum permissible width, number of bands, bit-depth are as follows- > max_width : (2 ^ 31) - 1 = 2147483647 > max_input_bands = 4 > max_bit_depth = 16 (2 Bytes) > > . As per the logic proposed in the fix, the intermediate bits per row would fit into a "long" variable but bytes per pixel would not fit into "int" variable. > // Fits into "long" data type > max_bits_per_row = max_width * max_input_bands * max_bit_depth > = 2147483647 x 4 x 16 > = 137438953408 > > // Does not fit into "int" data type > max_bytes_per_row = max_bits_per_row + 7 / 8 > = 17179869176 > = (0x 3FFFFFFF8 - Goes beyond 4B boundary) > > // Upon division by 2 for 16-bit images > max_elts_per_row = max_bytes_per_row / 2 > = 8589934588 > = (0x 1FFFFFFFC - Goes beyond 4B boundary) > > . If we intend to store bytes per row (and eltsPerRow which is scanline stride) in a "long" variable, the same cannot be sent to Raster APIs because the APIs accept "int" type for scanline stride in arguments list. > Going by the Raster APIs used in PNGImageReader, a proper fix would require changes to its APIs as well to handle such large scanline stride values. > > Thank you > Have a good day > > Prahalad N. > > ----- Original Message ----- > From: Jayathirth D V > Sent: Thursday, December 14, 2017 1:48 PM > To: 2d-dev > Subject: [OpenJDK 2D-Dev] RFR JDK-8191174: PngReader throws IllegalArgumentException because ScanlineStride calculation logic is not proper > > Hello All, > > Please review the following fix in JDK : > > Bug : https://bugs.openjdk.java.net/browse/JDK-8191174 > Webrev : http://cr.openjdk.java.net/~jdv/8191174/webrev.00/ > > Issue : When we try to read PNG image with large width we throw undocumented IllegalArgumentException with message "Pixel stride times width must be less than or equal to the scanline stride". > > Exception in thread "main" java.lang.IllegalArgumentException: Pixel stride times width must be less than or equal to the scanline stride > ??????????????? at java.desktop/java.awt.image.PixelInterleavedSampleModel.(PixelInterleavedSampleModel.java:101) > ??????????????? at java.desktop/java.awt.image.Raster.createInterleavedRaster(Raster.java:642) > ??????????????? at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.createRaster(PNGImageReader.java:974) > ??????????????? at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.decodePass(PNGImageReader.java:1099) > ??????????????? at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.decodeImage(PNGImageReader.java:1295) > ??????????????? at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.readImage(PNGImageReader.java:1420) > ??????????????? at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.read(PNGImageReader.java:1699) > ??????????????? at java.desktop/javax.imageio.ImageIO.read(ImageIO.java:1468) > ??????????????? at java.desktop/javax.imageio.ImageIO.read(ImageIO.java:1363) > ??????????????? at PngReaderLargeWidthStrideTest.main(PngReaderLargeWidthStrideTest.java:50) > > Root cause : We use large width present in IHDR and calculate elements per row which is passed as scanlinestride for creating the required raster and its corresponding sample model. ?When the call reaches creation of PixelInterleavedSampleModel it checks the condition of (pixelStride * w) > scanlineStride. Since in our case we pass this condition it throws IllegalArgumentException. We have invalid scanlineStride value because when we calculate elements per row/bytes per row value in PNGImageReader the integer variable buffer is overflowed and we maintain invalid value for bytesPerRow. > > Solution : We can maintain the intermediate bitsPerRow value in long datatype and calculate bytesPerRow using the long value and then typecast it to int bytesPerRow variable. By doing this we will maintain the required scanlineStride/eltsPerRow value properly. After this solution we will throw proper IIOException because of changes present in JDK-8190332 and not the undocumented IllegalArgumentException. > > Thanks, > Jay > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Sat Jan 6 09:34:06 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sat, 6 Jan 2018 01:34:06 -0800 Subject: [OpenJDK 2D-Dev] [11] RFR: [JDK-5064835] TextMeasurer/deleteChar function fails when deleting more than one characters In-Reply-To: References: <4c4a1107-5c91-4307-a467-715ea8ca992c@default> Message-ID: <8545b1c1-ba7e-7dea-cd03-00e910ab7ff3@oracle.com> Just small comment(for a discussion), about a performance of these methods. How much faster these methods from the case when the TextMeasure is created from scratch? I mean that if they are much faster and the insertChar() method works already, then probably we can support this in deleteChar as well? On 01/01/2018 22:53, Jayathirth D V wrote: > Hi Prahalad, > > Please find my inputs: > > Since we are making changes to deleteChar() code and specification I think we should make similar changes to insertChar() to make them behave in same way. I observed Jane Wang comment in JBS and tested inserting multiple character using TextMeasurer.insertChar() and it doesn't through ArrayIndexOutOfBoundsException or any other exception, it just initializes the text parameters using the newParagraph. > > We can make changes corresponding to insertChar() in the same bug or we can raise separate bug, but its better if we make changes to insertChar() also in the same JBS as they are similar change corresponding to identical behavior in same Class. > > Regarding JCK test fail, since we are targeting it to JDK 11 I think we have time to update the same without any risk. But we should get input from Phil/Others regarding the same. > > In the test case may be we can remove the System.out.println("Test passed."), since we know that if we don't get any exception/errors the jtreg test is passed. I see that some test cases have this "Test Passed" output but I feel it is redundant. > > Thanks, > Jay > > -----Original Message----- > From: Prahalad Kumar Narayanan > Sent: Friday, December 29, 2017 4:30 PM > To: 2d-dev > Subject: [OpenJDK 2D-Dev] [11] RFR: [JDK-5064835] TextMeasurer/deleteChar function fails when deleting more than one characters > > Hello Everyone > > Good day to you. > > Request your time in reviewing the fix for the bug: > JDK-5064835 TextMeasurer/deleteChar function fails when deleting more than one characters. > > Root Cause: > . The spec clearly mentions that the concerned method is to be used to delete a single character. > . However, the spec does not mention the outcome when the method is used to delete multiple characters (as reported in the bug) > > Solution Approaches: > . Since the spec does not mention the outcome when multiple characters are deleted, the result is left to the implementation. > . The solution can be approached in two perspectives- > 1. Update the spec to explicitly mention the exception that would be thrown in such cases or > 2. Re-initialize the TextMeasurer with the new text as present in the argument of the method. > > Solution: > . I inspected feasibility/ risk of both the approaches and I 'm of the opinion that approach 1. is better. > . Reason is that, with the second approach- > . The re-initialization would reset all text attributes, and state variabes that were set on TextMeasurer (and internal StyledParagraph) object. > . If re-initialization is required, one could create a new TextMeasurer using the modified text rather than invoking deleteChar method. > . Thus in the proposed solution- I 've added a throws clause that explicitly mentions that IllegalArgumentException will be thrown when attempted to delete multiple characters. > > Other Info: > . The fix was tested with existing jtreg test cases- No regressions were seen. > . 2 JCK tests have been found to fail. They are- > . java_awt/Font/TextMeasurer/CharTest (TestCase5) > . java_awt/Font/LineBreakMeasurer/CharTest (TestCase4) . In both the failures, incorrect arguments are passed to deleteChar method- newParagraph (with multiple chars deleted) & beginIndex (-1) . While the test case expects index out of bounds exception for -ve index, the code now throws IllegalArgumentsException. > . A minor correction to JCK test will fix the issue. I shall raise a JCK bug once the fix is approved & submitted. > > Kindly review the changes at your convenience & share your feedback: > http://cr.openjdk.java.net/~pnarayanan/5064835/webrev.00/ > > Note: I 've not raised a CSR for this bug yet. > Based on review, I will create the CSR for change to the specification. > > Thank you for your time in review & > Happy New Year > > Prahalad N. > -- Best regards, Sergey. From prahalad.kumar.narayanan at oracle.com Mon Jan 8 02:59:49 2018 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Sun, 7 Jan 2018 18:59:49 -0800 (PST) Subject: [OpenJDK 2D-Dev] [11] RFR: [JDK-8194489] Incorrect size computation at BandedSampleModel.createDataBuffer In-Reply-To: References: <516bdf7d-337a-4968-9320-2cd1f4e32b3d@default> Message-ID: <48685f82-aeae-4ac7-8c40-4710c539a8b7@default> Hello Sergey Thank you for your time in review. Here are some findings that might help in our discussion: . On Validating- scanlineStride, width, height with checks . When a user creates a BandedSampleModel object, the values of- scanlineStride, width and height are checked for non-negative values in the constructors. . The only additional check that is present in ComponentSampleModel 's getBufferSize method is the check for- (Integer.MAX_VALUE -1). . I don?t understand how this check helps. Does it avoid OutOfMemoryErrors during DataBuffer allocation? I'm not sure. . Hence, I didn't add additional validation to the fix proposed. . On Specification & throws clause: . I looked into the specification of createDataBuffer method in- BandedSampleModel & ComponentSampleModel . Banded sample model mentions- * @throws IllegalArgumentException if {@code dataType} is not * one of the supported data types */ . So if we wish to take up additional validation for our values- scanlineStride, width and height, we should update this spec as well. Kindly let me know your thoughts. . Surprisingly, ComponentSampleModel does not mention any throws clause in its spec for createDataBuffer method. But it throws quite a few IllegalArgumentExceptions in its getBufferSize invoked from createDataBuffer. . On ComponentSampleModel's Buffer Size Calculation . In addition to above points, the logic to calculate buffer size within ComponentSampleModel's getBufferSize() is incorrect. . The documentation of the class says that it can be used to store images that are- Band interleaved, Pixel interleaved & Scanline interleaved. . For each of the above types- the values of scanline stride, pixel stride, number of banks would vary. . But ComponentSampleModel 's getBufferSize seems to have a default logic that doesn't seem to consider these scenarios. . There is one open bug- https://bugs.openjdk.java.net/browse/JDK-6604105. Thank you for your review & this discussion Have a good day Prahalad N. -----Original Message----- From: Sergey Bylokhov Sent: Saturday, January 06, 2018 2:13 PM To: Prahalad Kumar Narayanan; 2d-dev Subject: Re: [OpenJDK 2D-Dev] [11] RFR: [JDK-8194489] Incorrect size computation at BandedSampleModel.createDataBuffer Hi, Prahalad. Not an expert here, but have a small question about implementation of this method in the parent class(ComponentSampleModel). Currently the parent class has a similar implementation of createDataBuffer(), but instead of "scanlineStride * height" it uses "getBufferSize()". And this "getBufferSize" has a number of additional checks, should not we do something similar here as well(see JDK-7058602)? On 04/01/2018 21:30, Prahalad Kumar Narayanan wrote: > Request your time to review the fix for the bug: > JDK-8194489 Incorrect size computation at BandedSampleModel . createDataBuffer > > Root Cause: > . The method BandedSampleModel . createDataBuffer does not consider number of banks and band offsets while computing the required memory size. > . As a result, ArrayIndexOutOfBounds exception is thrown when setting pixel values on banded sample models having - > . Multiple bands of image data stored in multiple banks of DataBuffer with band offsets > . Multiple bands of image data stored in single bank of > DataBuffer > > Solution: > . Appropriate logic has been added to createDataBuffer method. > > Other Info: > . All Jtreg test-cases in java/awt/image were run with the build including the fix. > . No regressions were noticed. > > Kindly review the changes at your convenience & share your feedback. > Link: http://cr.openjdk.java.net/~pnarayanan/8194489/webrev.00/ > > Thank you for your time in review > Have a good day > > Prahalad N. > -- Best regards, Sergey. From prahalad.kumar.narayanan at oracle.com Mon Jan 8 06:41:48 2018 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Sun, 7 Jan 2018 22:41:48 -0800 (PST) Subject: [OpenJDK 2D-Dev] [11] RFR: [JDK-5064835] TextMeasurer/deleteChar function fails when deleting more than one characters In-Reply-To: <8545b1c1-ba7e-7dea-cd03-00e910ab7ff3@oracle.com> References: <4c4a1107-5c91-4307-a467-715ea8ca992c@default> <8545b1c1-ba7e-7dea-cd03-00e910ab7ff3@oracle.com> Message-ID: <7fbe51b9-3a6f-4939-a378-f54f2b5ebd0d@default> Hello Sergey & Jay Thank you for your time in review & inputs. Please find my views herewith: . On Performance: . TextMeasurer's Constructor invokes : initAll(AttributedCharacterIterator text) method . initAll(AttributedCharacterIterator ) method further instantiates . fChars : new char[length] . fBidi : new Bidi . fParagraph : new StyledParagraph and so on. . The concerned method- deleteChar (and insertChar), invoke the same "initAll" method when number of characters deleted or inserted is more than one. . So from performance perspective, there shouldn't be a major difference between creating a new TextMeasurer and using deleteChar to delete more than few characters. . When methods invoke initAll, the text and its attributes are re-initialized and we would lose the text attributes originally set on TextMeasurer. . This is the reason why the proposed fix doesn't allow re-initialization and throws IllegalArgumentException when attempted to delete multiple chars. . On Modifying insertChar method's behavior . As Jay suggested, we should fix insertChar method's behavior to align with deleteChar method. . I was not sure whether we should make changes to insertChar as a separate bug /or alongside the current fix. . Nevertheless, I 've created a new webrev with the changes included for insertChar as well. . Impact from changes to insertChar are as follows- . No new regressions seen with JTreg test cases. . The change in insertChar introduces 4 JCK test failures making total count of JCK test failures to 6 . JCK tests that failed are: api/java_awt/Font/TextMeasurer/CharTest (Test cases: 1, 2, 5) api/java_awt/Font/LineBreakTextMeasurer/CharTest (Test cases: 1, 2, 4) . All the above test cases can be easily fixed with specification updated for the methods. Kindly review the updated changes at your convenience. Link: http://cr.openjdk.java.net/~pnarayanan/5064835/webrev.01/ Thank you once again Have a good day Prahalad N. -----Original Message----- From: Sergey Bylokhov Sent: Saturday, January 06, 2018 3:04 PM To: Jayathirth D V; Prahalad Kumar Narayanan; 2d-dev Subject: Re: [OpenJDK 2D-Dev] [11] RFR: [JDK-5064835] TextMeasurer/deleteChar function fails when deleting more than one characters Just small comment(for a discussion), about a performance of these methods. How much faster these methods from the case when the TextMeasure is created from scratch? I mean that if they are much faster and the insertChar() method works already, then probably we can support this in deleteChar as well? On 01/01/2018 22:53, Jayathirth D V wrote: > Hi Prahalad, > > Please find my inputs: > > Since we are making changes to deleteChar() code and specification I think we should make similar changes to insertChar() to make them behave in same way. I observed Jane Wang comment in JBS and tested inserting multiple character using TextMeasurer.insertChar() and it doesn't through ArrayIndexOutOfBoundsException or any other exception, it just initializes the text parameters using the newParagraph. > > We can make changes corresponding to insertChar() in the same bug or we can raise separate bug, but its better if we make changes to insertChar() also in the same JBS as they are similar change corresponding to identical behavior in same Class. > > Regarding JCK test fail, since we are targeting it to JDK 11 I think we have time to update the same without any risk. But we should get input from Phil/Others regarding the same. > > In the test case may be we can remove the System.out.println("Test passed."), since we know that if we don't get any exception/errors the jtreg test is passed. I see that some test cases have this "Test Passed" output but I feel it is redundant. > > Thanks, > Jay > > -----Original Message----- > From: Prahalad Kumar Narayanan > Sent: Friday, December 29, 2017 4:30 PM > To: 2d-dev > Subject: [OpenJDK 2D-Dev] [11] RFR: [JDK-5064835] > TextMeasurer/deleteChar function fails when deleting more than one > characters > > Hello Everyone > > Good day to you. > > Request your time in reviewing the fix for the bug: > JDK-5064835 TextMeasurer/deleteChar function fails when deleting more than one characters. > > Root Cause: > . The spec clearly mentions that the concerned method is to be used to delete a single character. > . However, the spec does not mention the outcome when the method is > used to delete multiple characters (as reported in the bug) > > Solution Approaches: > . Since the spec does not mention the outcome when multiple characters are deleted, the result is left to the implementation. > . The solution can be approached in two perspectives- > 1. Update the spec to explicitly mention the exception that would be thrown in such cases or > 2. Re-initialize the TextMeasurer with the new text as present in the argument of the method. > > Solution: > . I inspected feasibility/ risk of both the approaches and I 'm of the opinion that approach 1. is better. > . Reason is that, with the second approach- > . The re-initialization would reset all text attributes, and state variabes that were set on TextMeasurer (and internal StyledParagraph) object. > . If re-initialization is required, one could create a new TextMeasurer using the modified text rather than invoking deleteChar method. > . Thus in the proposed solution- I 've added a throws clause that explicitly mentions that IllegalArgumentException will be thrown when attempted to delete multiple characters. > > Other Info: > . The fix was tested with existing jtreg test cases- No regressions were seen. > . 2 JCK tests have been found to fail. They are- > . java_awt/Font/TextMeasurer/CharTest (TestCase5) > . java_awt/Font/LineBreakMeasurer/CharTest (TestCase4) . In both the failures, incorrect arguments are passed to deleteChar method- newParagraph (with multiple chars deleted) & beginIndex (-1) . While the test case expects index out of bounds exception for -ve index, the code now throws IllegalArgumentsException. > . A minor correction to JCK test will fix the issue. I shall raise a JCK bug once the fix is approved & submitted. > > Kindly review the changes at your convenience & share your feedback: > http://cr.openjdk.java.net/~pnarayanan/5064835/webrev.00/ > > Note: I 've not raised a CSR for this bug yet. > Based on review, I will create the CSR for change to the specification. > > Thank you for your time in review & > Happy New Year > > Prahalad N. > -- Best regards, Sergey. From jayathirth.d.v at oracle.com Mon Jan 8 07:23:50 2018 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Sun, 7 Jan 2018 23:23:50 -0800 (PST) Subject: [OpenJDK 2D-Dev] [11] RFR JDK-8191073: JpegImageReader throws IndexOutOfBoundsException when trying to read image data from tables-only image In-Reply-To: <21595BF6-0BAF-476A-90C2-B094354E65E3@oracle.com> References: <08c8a3eb-7a09-443e-b14b-689abbecf9fb@default> <21595BF6-0BAF-476A-90C2-B094354E65E3@oracle.com> Message-ID: <1082d318-302d-470c-8028-5145e17dfe43@default> Hi Brian, Thanks for your valuable inputs. As I was debugging the issue I started capturing this "tablesOnlyStream" boolean variable in checkTablesOnly() method and I started using it at other places also. As rightly pointed by you we don't need this "tablesOnlyStream" as it not used anywhere else and we can use imagePositions to know whether it is tables-only stream. I have removed the usage of tablesOnlyStream variable in code and updated the comment section. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/8191073/webrev.01/ Thanks, Jay From: Brian Burkhalter Sent: Saturday, January 06, 2018 4:43 AM To: Jayathirth D V Cc: 2d-dev Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-8191073: JpegImageReader throws IndexOutOfBoundsException when trying to read image data from tables-only image Hi Jay, On Jan 3, 2018, at 11:06 PM, Jayathirth D V wrote: Bug : https://bugs.openjdk.java.net/browse/JDK-8191073 Webrev : http://cr.openjdk.java.net/~jdv/8191073/webrev.00/ General comment: I think it's better to use "//" than "/*.*/" for method-internal comments: JpegImageReader L373-375, 392-397, 516-519 JpegTablesOnlyReadTest L61-64 As to the fix, is the new tablesOnlyStream boolean really necessary? For example at line 520 in the new version could not one do this if (imagePositions.isEmpty()) { // line 520 of new version throw new IIOException("No image data present to read"); } instead? I don't see where the value of this variable is used anywhere else. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Mon Jan 8 10:04:45 2018 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 8 Jan 2018 02:04:45 -0800 (PST) Subject: [OpenJDK 2D-Dev] RFR JDK-8191174: PngReader throws IllegalArgumentException because ScanlineStride calculation logic is not proper In-Reply-To: References: <6639d1ae-fa52-4505-af5f-1bf3e114fbe5@default> <4903dfdb-8c64-4a38-95e2-549f26b3ee41@default> <045c7f01-106f-4f01-a661-a82ab15c1b1c@default> <74518345-8ed6-44da-b384-01802c01368c@default> Message-ID: Hello Sergey, Thanks for your valuable inputs. As you have mentioned throwing "Pixel stride times width must be less than or equal to the scanline stride" is not proper in this scenario as image contains proper width as per PNG specification. Thanks for pointing to Math.multiplyExact() function and it is very beneficial for solving this issue. While calculating bytesPerRow itself we can use Math.multiplyExact() and throw "int overflow" ArithmeticException and it will be wrapped into IIOException because of changes present in https://bugs.openjdk.java.net/browse/JDK-8190332 . By doing this we will not have multiple "Caused by" chain and we will be throwing proper exception as per ImageIO specification. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/8191174/webrev.02/ Thanks, Jay -----Original Message----- From: Sergey Bylokhov Sent: Saturday, January 06, 2018 2:45 PM To: Prahalad Kumar Narayanan; Jayathirth D V; 2d-dev Subject: Re: [OpenJDK 2D-Dev] RFR JDK-8191174: PngReader throws IllegalArgumentException because ScanlineStride calculation logic is not proper Probably we can use Math.multiplyExact()? The current exception text wrapped a few times "Pixel stride times width must be less than or equal to the scanline stride" is not strictly correct because it is possible that the image itself has correct data, but we cannot handle it because of overflow. On 28/12/2017 22:49, Prahalad Kumar Narayanan wrote: > Hello Jay > > Good day to you. > > The code changes wrap the IllegalArgumentException in IIOException. > This approach is better & aligns with how OutOfMemoryError was wrapped to fix JDK-8190332. > > The only point that I 'm not sure is- whether we could wrap IllegalArgumentException twice before throwing to the user code. > > javax.imageio.IIOException: Error reading PNG image data > at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.readImage > at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.read > at java.desktop/javax.imageio.ImageIO.read > ... > Caused by: javax.imageio.IIOException: Caught exception during read: > at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.decodePass > at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.decodeImage > ... > Caused by: java.lang.IllegalArgumentException: Pixel stride times width must be less than or equal to the scanline stride > at java.desktop/java.awt.image.PixelInterleavedSampleModel. > at java.desktop/java.awt.image.Raster.createInterleavedRaster > at > java.desktop/com.sun.imageio.plugins.png.PNGImageReader.createRaster > > Since there are multiple levels of same exception, programmer could have trouble getting the cause using getCause() method. > However, Invoking printStackTrace() on the outer most exception object gives complete call stack (as listed above). > So I think, this should be ok. > > I would like to know of others' opinion too. > > Thank you > Have a good day > > Prahalad N. > > > -----Original Message----- > From: Jayathirth D V > Sent: Thursday, December 28, 2017 3:43 PM > To: Prahalad Kumar Narayanan; 2d-dev > Subject: RE: [OpenJDK 2D-Dev] RFR JDK-8191174: PngReader throws > IllegalArgumentException because ScanlineStride calculation logic is > not proper > > Hi Prahalad, > > Thanks for your valuable inputs. > > Even though the fix resolves the issue for the particular test case we have it will not solve the buffer overflow problem as you have mentioned in highest limit case or many other cases where the computed value is very high. > > Also we cannot change datatype of bytesPerRow/eltsPerRow as they are used in many passed to many other Raster and Stream API's. The best approach to resolve this issue would be to wrap the Exception that we are getting while creating Raster/SampleModel into an IIOException as we have done in https://bugs.openjdk.java.net/browse/JDK-8190332 . By doing this we will abide by specification and also we will have complete stack of why we got the exception so that it can be debugged properly in future. > > Please find updated webrev for review: > http://cr.openjdk.java.net/~jdv/8191174/webrev.01/ > > Thanks, > Jay > > -----Original Message----- > From: Prahalad Kumar Narayanan > Sent: Tuesday, December 19, 2017 3:08 PM > To: Jayathirth D V; 2d-dev > Subject: RE: [OpenJDK 2D-Dev] RFR JDK-8191174: PngReader throws > IllegalArgumentException because ScanlineStride calculation logic is > not proper > > > Hello Jay > > Good day to you. > > I don't think it's possible to fix this issue despite having intermediate " long " variable to hold intermediate bits per pixel. > Here is a simple math that considers the worst case scenario with max values: > > . As per the PNG specification, the maximum permissible width, number of bands, bit-depth are as follows- > max_width : (2 ^ 31) - 1 = 2147483647 > max_input_bands = 4 > max_bit_depth = 16 (2 Bytes) > > . As per the logic proposed in the fix, the intermediate bits per row would fit into a "long" variable but bytes per pixel would not fit into "int" variable. > // Fits into "long" data type > max_bits_per_row = max_width * max_input_bands * max_bit_depth > = 2147483647 x 4 x 16 > = 137438953408 > > // Does not fit into "int" data type > max_bytes_per_row = max_bits_per_row + 7 / 8 > = 17179869176 > = (0x 3FFFFFFF8 - > Goes beyond 4B boundary) > > // Upon division by 2 for 16-bit images > max_elts_per_row = max_bytes_per_row / 2 > = 8589934588 > = (0x 1FFFFFFFC - Goes > beyond 4B boundary) > > . If we intend to store bytes per row (and eltsPerRow which is scanline stride) in a "long" variable, the same cannot be sent to Raster APIs because the APIs accept "int" type for scanline stride in arguments list. > Going by the Raster APIs used in PNGImageReader, a proper fix would require changes to its APIs as well to handle such large scanline stride values. > > Thank you > Have a good day > > Prahalad N. > > ----- Original Message ----- > From: Jayathirth D V > Sent: Thursday, December 14, 2017 1:48 PM > To: 2d-dev > Subject: [OpenJDK 2D-Dev] RFR JDK-8191174: PngReader throws > IllegalArgumentException because ScanlineStride calculation logic is > not proper > > Hello All, > > Please review the following fix in JDK : > > Bug : https://bugs.openjdk.java.net/browse/JDK-8191174 > Webrev : http://cr.openjdk.java.net/~jdv/8191174/webrev.00/ > > Issue : When we try to read PNG image with large width we throw undocumented IllegalArgumentException with message "Pixel stride times width must be less than or equal to the scanline stride". > > Exception in thread "main" java.lang.IllegalArgumentException: Pixel > stride times width must be less than or equal to the scanline stride > ??????????????? at > java.desktop/java.awt.image.PixelInterleavedSampleModel.(PixelIn > terleavedSampleModel.java:101) > ??????????????? at > java.desktop/java.awt.image.Raster.createInterleavedRaster(Raster.java > :642) > ??????????????? at > java.desktop/com.sun.imageio.plugins.png.PNGImageReader.createRaster(P > NGImageReader.java:974) > ??????????????? at > java.desktop/com.sun.imageio.plugins.png.PNGImageReader.decodePass(PNG > ImageReader.java:1099) > ??????????????? at > java.desktop/com.sun.imageio.plugins.png.PNGImageReader.decodeImage(PN > GImageReader.java:1295) > ??????????????? at > java.desktop/com.sun.imageio.plugins.png.PNGImageReader.readImage(PNGI > mageReader.java:1420) > ??????????????? at > java.desktop/com.sun.imageio.plugins.png.PNGImageReader.read(PNGImageR > eader.java:1699) > ??????????????? at > java.desktop/javax.imageio.ImageIO.read(ImageIO.java:1468) > ??????????????? at > java.desktop/javax.imageio.ImageIO.read(ImageIO.java:1363) > ??????????????? at > PngReaderLargeWidthStrideTest.main(PngReaderLargeWidthStrideTest.java: > 50) > > Root cause : We use large width present in IHDR and calculate elements per row which is passed as scanlinestride for creating the required raster and its corresponding sample model. ?When the call reaches creation of PixelInterleavedSampleModel it checks the condition of (pixelStride * w) > scanlineStride. Since in our case we pass this condition it throws IllegalArgumentException. We have invalid scanlineStride value because when we calculate elements per row/bytes per row value in PNGImageReader the integer variable buffer is overflowed and we maintain invalid value for bytesPerRow. > > Solution : We can maintain the intermediate bitsPerRow value in long datatype and calculate bytesPerRow using the long value and then typecast it to int bytesPerRow variable. By doing this we will maintain the required scanlineStride/eltsPerRow value properly. After this solution we will throw proper IIOException because of changes present in JDK-8190332 and not the undocumented IllegalArgumentException. > > Thanks, > Jay > -- Best regards, Sergey. From jayathirth.d.v at oracle.com Mon Jan 8 10:51:32 2018 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 8 Jan 2018 02:51:32 -0800 (PST) Subject: [OpenJDK 2D-Dev] [11] RFR: [JDK-5064835] TextMeasurer/deleteChar function fails when deleting more than one characters In-Reply-To: <7fbe51b9-3a6f-4939-a378-f54f2b5ebd0d@default> References: <4c4a1107-5c91-4307-a467-715ea8ca992c@default> <8545b1c1-ba7e-7dea-cd03-00e910ab7ff3@oracle.com> <7fbe51b9-3a6f-4939-a378-f54f2b5ebd0d@default> Message-ID: Hi Prahalad, Changes in insertChar() are also fine. I noticed a small correction in indentation for which there is no need for another webrev. At line number 674 & 738. We should maintain space between operands and operator. if (end - start != fChars.length+1) { -> if (end - start != fChars.length + 1) { & if (end - start != fChars.length-1) { -> if (end - start != fChars.length - 1) { Thanks, Jay -----Original Message----- From: Prahalad Kumar Narayanan Sent: Monday, January 08, 2018 12:12 PM To: Sergey Bylokhov; Jayathirth D V; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR: [JDK-5064835] TextMeasurer/deleteChar function fails when deleting more than one characters Hello Sergey & Jay Thank you for your time in review & inputs. Please find my views herewith: . On Performance: . TextMeasurer's Constructor invokes : initAll(AttributedCharacterIterator text) method . initAll(AttributedCharacterIterator ) method further instantiates . fChars : new char[length] . fBidi : new Bidi . fParagraph : new StyledParagraph and so on. . The concerned method- deleteChar (and insertChar), invoke the same "initAll" method when number of characters deleted or inserted is more than one. . So from performance perspective, there shouldn't be a major difference between creating a new TextMeasurer and using deleteChar to delete more than few characters. . When methods invoke initAll, the text and its attributes are re-initialized and we would lose the text attributes originally set on TextMeasurer. . This is the reason why the proposed fix doesn't allow re-initialization and throws IllegalArgumentException when attempted to delete multiple chars. . On Modifying insertChar method's behavior . As Jay suggested, we should fix insertChar method's behavior to align with deleteChar method. . I was not sure whether we should make changes to insertChar as a separate bug /or alongside the current fix. . Nevertheless, I 've created a new webrev with the changes included for insertChar as well. . Impact from changes to insertChar are as follows- . No new regressions seen with JTreg test cases. . The change in insertChar introduces 4 JCK test failures making total count of JCK test failures to 6 . JCK tests that failed are: api/java_awt/Font/TextMeasurer/CharTest (Test cases: 1, 2, 5) api/java_awt/Font/LineBreakTextMeasurer/CharTest (Test cases: 1, 2, 4) . All the above test cases can be easily fixed with specification updated for the methods. Kindly review the updated changes at your convenience. Link: http://cr.openjdk.java.net/~pnarayanan/5064835/webrev.01/ Thank you once again Have a good day Prahalad N. -----Original Message----- From: Sergey Bylokhov Sent: Saturday, January 06, 2018 3:04 PM To: Jayathirth D V; Prahalad Kumar Narayanan; 2d-dev Subject: Re: [OpenJDK 2D-Dev] [11] RFR: [JDK-5064835] TextMeasurer/deleteChar function fails when deleting more than one characters Just small comment(for a discussion), about a performance of these methods. How much faster these methods from the case when the TextMeasure is created from scratch? I mean that if they are much faster and the insertChar() method works already, then probably we can support this in deleteChar as well? On 01/01/2018 22:53, Jayathirth D V wrote: > Hi Prahalad, > > Please find my inputs: > > Since we are making changes to deleteChar() code and specification I think we should make similar changes to insertChar() to make them behave in same way. I observed Jane Wang comment in JBS and tested inserting multiple character using TextMeasurer.insertChar() and it doesn't through ArrayIndexOutOfBoundsException or any other exception, it just initializes the text parameters using the newParagraph. > > We can make changes corresponding to insertChar() in the same bug or we can raise separate bug, but its better if we make changes to insertChar() also in the same JBS as they are similar change corresponding to identical behavior in same Class. > > Regarding JCK test fail, since we are targeting it to JDK 11 I think we have time to update the same without any risk. But we should get input from Phil/Others regarding the same. > > In the test case may be we can remove the System.out.println("Test passed."), since we know that if we don't get any exception/errors the jtreg test is passed. I see that some test cases have this "Test Passed" output but I feel it is redundant. > > Thanks, > Jay > > -----Original Message----- > From: Prahalad Kumar Narayanan > Sent: Friday, December 29, 2017 4:30 PM > To: 2d-dev > Subject: [OpenJDK 2D-Dev] [11] RFR: [JDK-5064835] > TextMeasurer/deleteChar function fails when deleting more than one > characters > > Hello Everyone > > Good day to you. > > Request your time in reviewing the fix for the bug: > JDK-5064835 TextMeasurer/deleteChar function fails when deleting more than one characters. > > Root Cause: > . The spec clearly mentions that the concerned method is to be used to delete a single character. > . However, the spec does not mention the outcome when the method is > used to delete multiple characters (as reported in the bug) > > Solution Approaches: > . Since the spec does not mention the outcome when multiple characters are deleted, the result is left to the implementation. > . The solution can be approached in two perspectives- > 1. Update the spec to explicitly mention the exception that would be thrown in such cases or > 2. Re-initialize the TextMeasurer with the new text as present in the argument of the method. > > Solution: > . I inspected feasibility/ risk of both the approaches and I 'm of the opinion that approach 1. is better. > . Reason is that, with the second approach- > . The re-initialization would reset all text attributes, and state variabes that were set on TextMeasurer (and internal StyledParagraph) object. > . If re-initialization is required, one could create a new TextMeasurer using the modified text rather than invoking deleteChar method. > . Thus in the proposed solution- I 've added a throws clause that explicitly mentions that IllegalArgumentException will be thrown when attempted to delete multiple characters. > > Other Info: > . The fix was tested with existing jtreg test cases- No regressions were seen. > . 2 JCK tests have been found to fail. They are- > . java_awt/Font/TextMeasurer/CharTest (TestCase5) > . java_awt/Font/LineBreakMeasurer/CharTest (TestCase4) . In both the failures, incorrect arguments are passed to deleteChar method- newParagraph (with multiple chars deleted) & beginIndex (-1) . While the test case expects index out of bounds exception for -ve index, the code now throws IllegalArgumentsException. > . A minor correction to JCK test will fix the issue. I shall raise a JCK bug once the fix is approved & submitted. > > Kindly review the changes at your convenience & share your feedback: > http://cr.openjdk.java.net/~pnarayanan/5064835/webrev.00/ > > Note: I 've not raised a CSR for this bug yet. > Based on review, I will create the CSR for change to the specification. > > Thank you for your time in review & > Happy New Year > > Prahalad N. > -- Best regards, Sergey. From brian.burkhalter at oracle.com Mon Jan 8 21:00:16 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 8 Jan 2018 13:00:16 -0800 Subject: [OpenJDK 2D-Dev] [11] RFR JDK-8191073: JpegImageReader throws IndexOutOfBoundsException when trying to read image data from tables-only image In-Reply-To: <1082d318-302d-470c-8028-5145e17dfe43@default> References: <08c8a3eb-7a09-443e-b14b-689abbecf9fb@default> <21595BF6-0BAF-476A-90C2-B094354E65E3@oracle.com> <1082d318-302d-470c-8028-5145e17dfe43@default> Message-ID: Hi Jay, Sorry but I have a few picky comments. 377 // If imagePositions list doesn't contain any of the image stream 378 // starting position(i.e tables-only image) we should not try to access 379 // imagePositions.size() as it done below, because it will lead to 380 // IndexOutOfBoundsException with index -1. You might consider this verbiage instead: If the image positions list is empty as in the case of a tables-only stream, then attempting to access the element at index imagePositions.size() - 1 will cause an IndexOutOfBoundsException. 381 if (seekForwardOnly && (!(imagePositions.isEmpty()))) { I think this is more readable if some parentheses are eliminated: 381 if (seekForwardOnly && !imagePositions.isEmpty()) { 499 // We should not try to read image information from an input stream 500 // which only contains tables-only(StreamMetadata) information. You might consider this verbiage instead: If the image positions list is empty as in the case of a tables-only stream, then no image data can be read. No need to update the webrev. Thanks, Brian On Jan 7, 2018, at 11:23 PM, Jayathirth D V wrote: > I have removed the usage of tablesOnlyStream variable in code and updated the comment section. > Please find updated webrev for review: > http://cr.openjdk.java.net/~jdv/8191073/webrev.01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From prahalad.kumar.narayanan at oracle.com Tue Jan 9 06:50:22 2018 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Mon, 8 Jan 2018 22:50:22 -0800 (PST) Subject: [OpenJDK 2D-Dev] RFR JDK-8191174: PngReader throws IllegalArgumentException because ScanlineStride calculation logic is not proper In-Reply-To: References: <6639d1ae-fa52-4505-af5f-1bf3e114fbe5@default> <4903dfdb-8c64-4a38-95e2-549f26b3ee41@default> <045c7f01-106f-4f01-a661-a82ab15c1b1c@default> <74518345-8ed6-44da-b384-01802c01368c@default> Message-ID: <4faf5f29-5184-4ee1-953e-001aaffedb1d@default> Hello Jay The change looks good. Thanks Have a good day Prahalad N. -----Original Message----- From: Jayathirth D V Sent: Monday, January 08, 2018 3:35 PM To: Sergey Bylokhov; 2d-dev Subject: Re: [OpenJDK 2D-Dev] RFR JDK-8191174: PngReader throws IllegalArgumentException because ScanlineStride calculation logic is not proper Hello Sergey, Thanks for your valuable inputs. As you have mentioned throwing "Pixel stride times width must be less than or equal to the scanline stride" is not proper in this scenario as image contains proper width as per PNG specification. Thanks for pointing to Math.multiplyExact() function and it is very beneficial for solving this issue. While calculating bytesPerRow itself we can use Math.multiplyExact() and throw "int overflow" ArithmeticException and it will be wrapped into IIOException because of changes present in https://bugs.openjdk.java.net/browse/JDK-8190332 . By doing this we will not have multiple "Caused by" chain and we will be throwing proper exception as per ImageIO specification. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/8191174/webrev.02/ Thanks, Jay -----Original Message----- From: Sergey Bylokhov Sent: Saturday, January 06, 2018 2:45 PM To: Prahalad Kumar Narayanan; Jayathirth D V; 2d-dev Subject: Re: [OpenJDK 2D-Dev] RFR JDK-8191174: PngReader throws IllegalArgumentException because ScanlineStride calculation logic is not proper Probably we can use Math.multiplyExact()? The current exception text wrapped a few times "Pixel stride times width must be less than or equal to the scanline stride" is not strictly correct because it is possible that the image itself has correct data, but we cannot handle it because of overflow. On 28/12/2017 22:49, Prahalad Kumar Narayanan wrote: > Hello Jay > > Good day to you. > > The code changes wrap the IllegalArgumentException in IIOException. > This approach is better & aligns with how OutOfMemoryError was wrapped to fix JDK-8190332. > > The only point that I 'm not sure is- whether we could wrap IllegalArgumentException twice before throwing to the user code. > > javax.imageio.IIOException: Error reading PNG image data > at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.readImage > at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.read > at java.desktop/javax.imageio.ImageIO.read > ... > Caused by: javax.imageio.IIOException: Caught exception during read: > at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.decodePass > at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.decodeImage > ... > Caused by: java.lang.IllegalArgumentException: Pixel stride times width must be less than or equal to the scanline stride > at java.desktop/java.awt.image.PixelInterleavedSampleModel. > at java.desktop/java.awt.image.Raster.createInterleavedRaster > at > java.desktop/com.sun.imageio.plugins.png.PNGImageReader.createRaster > > Since there are multiple levels of same exception, programmer could have trouble getting the cause using getCause() method. > However, Invoking printStackTrace() on the outer most exception object gives complete call stack (as listed above). > So I think, this should be ok. > > I would like to know of others' opinion too. > > Thank you > Have a good day > > Prahalad N. > > > -----Original Message----- > From: Jayathirth D V > Sent: Thursday, December 28, 2017 3:43 PM > To: Prahalad Kumar Narayanan; 2d-dev > Subject: RE: [OpenJDK 2D-Dev] RFR JDK-8191174: PngReader throws > IllegalArgumentException because ScanlineStride calculation logic is > not proper > > Hi Prahalad, > > Thanks for your valuable inputs. > > Even though the fix resolves the issue for the particular test case we have it will not solve the buffer overflow problem as you have mentioned in highest limit case or many other cases where the computed value is very high. > > Also we cannot change datatype of bytesPerRow/eltsPerRow as they are used in many passed to many other Raster and Stream API's. The best approach to resolve this issue would be to wrap the Exception that we are getting while creating Raster/SampleModel into an IIOException as we have done in https://bugs.openjdk.java.net/browse/JDK-8190332 . By doing this we will abide by specification and also we will have complete stack of why we got the exception so that it can be debugged properly in future. > > Please find updated webrev for review: > http://cr.openjdk.java.net/~jdv/8191174/webrev.01/ > > Thanks, > Jay > > -----Original Message----- > From: Prahalad Kumar Narayanan > Sent: Tuesday, December 19, 2017 3:08 PM > To: Jayathirth D V; 2d-dev > Subject: RE: [OpenJDK 2D-Dev] RFR JDK-8191174: PngReader throws > IllegalArgumentException because ScanlineStride calculation logic is > not proper > > > Hello Jay > > Good day to you. > > I don't think it's possible to fix this issue despite having intermediate " long " variable to hold intermediate bits per pixel. > Here is a simple math that considers the worst case scenario with max values: > > . As per the PNG specification, the maximum permissible width, number of bands, bit-depth are as follows- > max_width : (2 ^ 31) - 1 = 2147483647 > max_input_bands = 4 > max_bit_depth = 16 (2 Bytes) > > . As per the logic proposed in the fix, the intermediate bits per row would fit into a "long" variable but bytes per pixel would not fit into "int" variable. > // Fits into "long" data type > max_bits_per_row = max_width * max_input_bands * max_bit_depth > = 2147483647 x 4 x 16 > = 137438953408 > > // Does not fit into "int" data type > max_bytes_per_row = max_bits_per_row + 7 / 8 > = 17179869176 > = (0x 3FFFFFFF8 - > Goes beyond 4B boundary) > > // Upon division by 2 for 16-bit images > max_elts_per_row = max_bytes_per_row / 2 > = 8589934588 > = (0x 1FFFFFFFC - Goes > beyond 4B boundary) > > . If we intend to store bytes per row (and eltsPerRow which is scanline stride) in a "long" variable, the same cannot be sent to Raster APIs because the APIs accept "int" type for scanline stride in arguments list. > Going by the Raster APIs used in PNGImageReader, a proper fix would require changes to its APIs as well to handle such large scanline stride values. > > Thank you > Have a good day > > Prahalad N. > > ----- Original Message ----- > From: Jayathirth D V > Sent: Thursday, December 14, 2017 1:48 PM > To: 2d-dev > Subject: [OpenJDK 2D-Dev] RFR JDK-8191174: PngReader throws > IllegalArgumentException because ScanlineStride calculation logic is > not proper > > Hello All, > > Please review the following fix in JDK : > > Bug : https://bugs.openjdk.java.net/browse/JDK-8191174 > Webrev : http://cr.openjdk.java.net/~jdv/8191174/webrev.00/ > > Issue : When we try to read PNG image with large width we throw undocumented IllegalArgumentException with message "Pixel stride times width must be less than or equal to the scanline stride". > > Exception in thread "main" java.lang.IllegalArgumentException: Pixel > stride times width must be less than or equal to the scanline stride > ??????????????? at > java.desktop/java.awt.image.PixelInterleavedSampleModel.(PixelIn > terleavedSampleModel.java:101) > ??????????????? at > java.desktop/java.awt.image.Raster.createInterleavedRaster(Raster.java > :642) > ??????????????? at > java.desktop/com.sun.imageio.plugins.png.PNGImageReader.createRaster(P > NGImageReader.java:974) > ??????????????? at > java.desktop/com.sun.imageio.plugins.png.PNGImageReader.decodePass(PNG > ImageReader.java:1099) > ??????????????? at > java.desktop/com.sun.imageio.plugins.png.PNGImageReader.decodeImage(PN > GImageReader.java:1295) > ??????????????? at > java.desktop/com.sun.imageio.plugins.png.PNGImageReader.readImage(PNGI > mageReader.java:1420) > ??????????????? at > java.desktop/com.sun.imageio.plugins.png.PNGImageReader.read(PNGImageR > eader.java:1699) > ??????????????? at > java.desktop/javax.imageio.ImageIO.read(ImageIO.java:1468) > ??????????????? at > java.desktop/javax.imageio.ImageIO.read(ImageIO.java:1363) > ??????????????? at > PngReaderLargeWidthStrideTest.main(PngReaderLargeWidthStrideTest.java: > 50) > > Root cause : We use large width present in IHDR and calculate elements per row which is passed as scanlinestride for creating the required raster and its corresponding sample model. ?When the call reaches creation of PixelInterleavedSampleModel it checks the condition of (pixelStride * w) > scanlineStride. Since in our case we pass this condition it throws IllegalArgumentException. We have invalid scanlineStride value because when we calculate elements per row/bytes per row value in PNGImageReader the integer variable buffer is overflowed and we maintain invalid value for bytesPerRow. > > Solution : We can maintain the intermediate bitsPerRow value in long datatype and calculate bytesPerRow using the long value and then typecast it to int bytesPerRow variable. By doing this we will maintain the required scanlineStride/eltsPerRow value properly. After this solution we will throw proper IIOException because of changes present in JDK-8190332 and not the undocumented IllegalArgumentException. > > Thanks, > Jay > -- Best regards, Sergey. From jayathirth.d.v at oracle.com Tue Jan 9 08:29:50 2018 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Tue, 9 Jan 2018 00:29:50 -0800 (PST) Subject: [OpenJDK 2D-Dev] [11] RFR JDK-8191073: JpegImageReader throws IndexOutOfBoundsException when trying to read image data from tables-only image In-Reply-To: References: <08c8a3eb-7a09-443e-b14b-689abbecf9fb@default> <21595BF6-0BAF-476A-90C2-B094354E65E3@oracle.com> <1082d318-302d-470c-8028-5145e17dfe43@default> Message-ID: <81d82ff9-12d8-4d85-87d1-df703fbc0390@default> Hello Brian, Thanks for reviewing the changes. I am posting updated webrev since I need one more review and approval from 2d-dev list. Updated webrev for review : http://cr.openjdk.java.net/~jdv/8191073/webrev.02/ Thanks, Jay From: Brian Burkhalter Sent: Tuesday, January 09, 2018 2:30 AM To: Jayathirth D V Cc: 2d-dev Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-8191073: JpegImageReader throws IndexOutOfBoundsException when trying to read image data from tables-only image Hi Jay, Sorry but I have a few picky comments. 377 // If imagePositions list doesn't contain any of the image stream 378 // starting position(i.e tables-only image) we should not try to access 379 // imagePositions.size() as it done below, because it will lead to 380 // IndexOutOfBoundsException with index -1. You might consider this verbiage instead: If the image positions list is empty as in the case of a tables-only stream, then attempting to access the element at index imagePositions.size() - 1 will cause an IndexOutOfBoundsException. 381 if (seekForwardOnly && (!(imagePositions.isEmpty()))) { I think this is more readable if some parentheses are eliminated: 381 if (seekForwardOnly && !imagePositions.isEmpty()) { 499 // We should not try to read image information from an input stream 500 // which only contains tables-only(StreamMetadata) information. You might consider this verbiage instead: If the image positions list is empty as in the case of a tables-only stream, then no image data can be read. No need to update the webrev. Thanks, Brian On Jan 7, 2018, at 11:23 PM, Jayathirth D V wrote: I have removed the usage of tablesOnlyStream variable in code and updated the comment section. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/8191073/webrev.01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From prahalad.kumar.narayanan at oracle.com Tue Jan 9 11:42:33 2018 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Tue, 9 Jan 2018 03:42:33 -0800 (PST) Subject: [OpenJDK 2D-Dev] [11] RFR: [JDK-8194489] Incorrect size computation at BandedSampleModel.createDataBuffer In-Reply-To: <8A71DE42-66E1-4CC7-A0B9-FFA71F021A1F@oracle.com> References: <516bdf7d-337a-4968-9320-2cd1f4e32b3d@default> <8A71DE42-66E1-4CC7-A0B9-FFA71F021A1F@oracle.com> Message-ID: <28bf0ec6-5376-4e59-b765-93867066c71d@default> Hello Brian Thank you for your time in review & suggestions. > BandedSampleModel > L193-196 and 203-207: In general I think it's better for method-internal comments to use the "//" form instead of the "/*.*/" form. My views: . I find interspersed use of // and /* */ for multi-line comments in our client libs code. . For example: The D3DBlitLoops uses "//" while many parts of Image IO use /* ... */ for multi-line comments. . While implementing the fix, I try to maintain uniformity established by the file getting modified. . In general, I refer to this guideline- http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html > BandedSampleModelSizeTest > Instead of defining the utility methods compareSamples(int[],int[]) and initSamples(int[],int) > you might consider simply using j.u.Arrays.equals(int[],int[]) and j.u.Arrays.fill(int[],int), respectively. My views: . Thank you for the suggestion. It helped. . I 've modified the test code to use Arrays.fill and Arrays.equals methods. The modified code is now available for review under Link: http://cr.openjdk.java.net/~pnarayanan/8194489/webrev.01/ Kindly review at your convenience and share your thoughts. Thank you for your time in review Have a good day Prahalad N. ----- Original Message ----- From: Brian Burkhalter Sent: Saturday, January 06, 2018 4:22 AM To: Prahalad Kumar Narayanan Cc: 2d-dev Subject: Re: [OpenJDK 2D-Dev] [11] RFR: [JDK-8194489] Incorrect size computation at BandedSampleModel.createDataBuffer Hello Prahalad, On Jan 4, 2018, at 9:30 PM, Prahalad Kumar Narayanan wrote: Request your time to review the fix for the bug: JDK-8194489 ???Incorrect size computation at BandedSampleModel . createDataBuffer https://bugs.openjdk.java.net/browse/JDK-8194489 Kindly review the changes at your convenience & share your feedback. Link:?http://cr.openjdk.java.net/~pnarayanan/8194489/webrev.00/ In general I think this looks good. A few comments: BandedSampleModel L193-196 and 203-207: In general I think it's better for method-internal comments to use the "//" form instead of the "/*.*/" form. BandedSampleModelSizeTest Instead of defining the utility methods compareSamples(int[],int[]) and initSamples(int[],int) you might consider simply using j.u.Arrays.equals(int[],int[]) and j.u.Arrays.fill(int[],int), respectively. Thanks, Brian From brian.burkhalter at oracle.com Wed Jan 10 01:21:52 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 9 Jan 2018 17:21:52 -0800 Subject: [OpenJDK 2D-Dev] [11] RFR: [JDK-8194489] Incorrect size computation at BandedSampleModel.createDataBuffer In-Reply-To: <28bf0ec6-5376-4e59-b765-93867066c71d@default> References: <516bdf7d-337a-4968-9320-2cd1f4e32b3d@default> <8A71DE42-66E1-4CC7-A0B9-FFA71F021A1F@oracle.com> <28bf0ec6-5376-4e59-b765-93867066c71d@default> Message-ID: Hi Prahalad, On Jan 9, 2018, at 3:42 AM, Prahalad Kumar Narayanan wrote: >> BandedSampleModel >> L193-196 and 203-207: In general I think it's better for method-internal comments to use the "//" form instead of the "/*.*/" form. > My views: > . I find interspersed use of // and /* */ for multi-line comments in our client libs code. > . For example: The D3DBlitLoops uses "//" while many parts of Image IO use /* ... */ for multi-line comments. > . While implementing the fix, I try to maintain uniformity established by the file getting modified. I think that is a good approach. > . In general, I refer to this guideline- http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html For the record I tend to prefer the ?//? for intra-method comments as I have found that not infrequently in debugging one needs to comment out a section and this is much easier to do if the comments in question do not use the ?/*?*/? style. I think you can leave this one as-is however. >> BandedSampleModelSizeTest >> Instead of defining the utility methods compareSamples(int[],int[]) and initSamples(int[],int) >> you might consider simply using j.u.Arrays.equals(int[],int[]) and j.u.Arrays.fill(int[],int), respectively. > My views: > . Thank you for the suggestion. It helped. > . I 've modified the test code to use Arrays.fill and Arrays.equals methods. > > The modified code is now available for review under > Link: http://cr.openjdk.java.net/~pnarayanan/8194489/webrev.01/ > > Kindly review at your convenience and share your thoughts. I think this looks OK. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Wed Jan 10 01:25:26 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 9 Jan 2018 17:25:26 -0800 Subject: [OpenJDK 2D-Dev] RFR JDK-8191174: PngReader throws IllegalArgumentException because ScanlineStride calculation logic is not proper In-Reply-To: <4faf5f29-5184-4ee1-953e-001aaffedb1d@default> References: <6639d1ae-fa52-4505-af5f-1bf3e114fbe5@default> <4903dfdb-8c64-4a38-95e2-549f26b3ee41@default> <045c7f01-106f-4f01-a661-a82ab15c1b1c@default> <74518345-8ed6-44da-b384-01802c01368c@default> <4faf5f29-5184-4ee1-953e-001aaffedb1d@default> Message-ID: <0E0B2816-3C47-4C72-B9AC-D9248575B7DB@oracle.com> Hi Jay, +1 Brian On Jan 8, 2018, at 10:50 PM, Prahalad Kumar Narayanan wrote: > The change looks good. > > [?] > Please find updated webrev for review: > http://cr.openjdk.java.net/~jdv/8191174/webrev.02/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From prahalad.kumar.narayanan at oracle.com Wed Jan 10 06:04:38 2018 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Tue, 9 Jan 2018 22:04:38 -0800 (PST) Subject: [OpenJDK 2D-Dev] [11] RFR JDK-8191073: JpegImageReader throws IndexOutOfBoundsException when trying to read image data from tables-only image In-Reply-To: <81d82ff9-12d8-4d85-87d1-df703fbc0390@default> References: <08c8a3eb-7a09-443e-b14b-689abbecf9fb@default> <21595BF6-0BAF-476A-90C2-B094354E65E3@oracle.com> <1082d318-302d-470c-8028-5145e17dfe43@default> <81d82ff9-12d8-4d85-87d1-df703fbc0390@default> Message-ID: Hello Jay I imported your changes & tested the same. The change doesn't cause new regressions & attached test case passes. Looks good. Thank you Have a good day Prahalad N. ----- Original Message ----- From: Jayathirth D V Sent: Tuesday, January 09, 2018 2:00 PM To: Brian Burkhalter; 2d-dev Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-8191073: JpegImageReader throws IndexOutOfBoundsException when trying to read image data from tables-only image Hello Brian, Thanks for reviewing the changes. I am posting updated webrev since I need one more review and approval ?from 2d-dev list. Updated webrev for review : http://cr.openjdk.java.net/~jdv/8191073/webrev.02/ Thanks, Jay From: Brian Burkhalter Sent: Tuesday, January 09, 2018 2:30 AM To: Jayathirth D V Cc: 2d-dev Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-8191073: JpegImageReader throws IndexOutOfBoundsException when trying to read image data from tables-only image Hi Jay, Sorry but I have a few picky comments. ?377 ? ? ? ? // If imagePositions list doesn't contain any of the image stream ?378 ? ? ? ? // starting position(i.e tables-only image) we should not try to access ?379 ? ? ? ? // imagePositions.size() as it done below, because it will lead to ?380 ? ? ? ? // IndexOutOfBoundsException with index -1. You might consider this verbiage instead: If the image positions list is empty as in the case of a tables-only stream, then attempting to access the element at index imagePositions.size() - 1 will cause an IndexOutOfBoundsException. ?381 ? ? ? ? if (seekForwardOnly && (!(imagePositions.isEmpty()))) { I think this is more readable if some parentheses are eliminated: ?381 ? ? ? ? if (seekForwardOnly && !imagePositions.isEmpty()) { ?499 ? ? ? ? // We should not try to read image information from an input stream ?500 ? ? ? ? // which only contains tables-only(StreamMetadata) information. You might consider this verbiage instead: If the image positions list is empty as in the case of a tables-only stream, then no image data can be read. No need to update the webrev. Thanks, Brian On Jan 7, 2018, at 11:23 PM, Jayathirth D V wrote: I have removed the usage of tablesOnlyStream variable in code and updated the comment section. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/8191073/webrev.01/ From jayathirth.d.v at oracle.com Wed Jan 10 12:00:29 2018 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Wed, 10 Jan 2018 04:00:29 -0800 (PST) Subject: [OpenJDK 2D-Dev] [11] RFR: [JDK-8194489] Incorrect size computation at BandedSampleModel.createDataBuffer In-Reply-To: References: <516bdf7d-337a-4968-9320-2cd1f4e32b3d@default> <8A71DE42-66E1-4CC7-A0B9-FFA71F021A1F@oracle.com> <28bf0ec6-5376-4e59-b765-93867066c71d@default> Message-ID: Hi Prahalad, Change looks good to me. Thanks, Jay From: Brian Burkhalter Sent: Wednesday, January 10, 2018 6:52 AM To: Prahalad Kumar Narayanan Cc: 2d-dev Subject: Re: [OpenJDK 2D-Dev] [11] RFR: [JDK-8194489] Incorrect size computation at BandedSampleModel.createDataBuffer Hi Prahalad, On Jan 9, 2018, at 3:42 AM, Prahalad Kumar Narayanan wrote: BandedSampleModel L193-196 and 203-207: In general I think it's better for method-internal comments to use the "//" form instead of the "/*.*/" form. My views: . I find interspersed use of // and /* */ for multi-line comments in our client libs code. . For example: The D3DBlitLoops uses "//" while many parts of Image IO use /* ... */ for multi-line comments. . While implementing the fix, I try to maintain uniformity established by the file getting modified. I think that is a good approach. . In general, I refer to this guideline- http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html For the record I tend to prefer the "//" for intra-method comments as I have found that not infrequently in debugging one needs to comment out a section and this is much easier to do if the comments in question do not use the "/*.*/" style. I think you can leave this one as-is however. BandedSampleModelSizeTest Instead of defining the utility methods compareSamples(int[],int[]) and initSamples(int[],int) you might consider simply using j.u.Arrays.equals(int[],int[]) and j.u.Arrays.fill(int[],int), respectively. My views: . Thank you for the suggestion. It helped. . I 've modified the test code to use Arrays.fill and Arrays.equals methods. The modified code is now available for review under Link: http://cr.openjdk.java.net/~pnarayanan/8194489/webrev.01/ Kindly review at your convenience and share your thoughts. I think this looks OK. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri Jan 12 22:03:48 2018 From: philip.race at oracle.com (Phil Race) Date: Fri, 12 Jan 2018 14:03:48 -0800 Subject: [OpenJDK 2D-Dev] [11] RFR: [JDK-5064835] TextMeasurer/deleteChar function fails when deleting more than one characters In-Reply-To: <4c4a1107-5c91-4307-a467-715ea8ca992c@default> References: <4c4a1107-5c91-4307-a467-715ea8ca992c@default> Message-ID: I think we need to divine what the authors of the method intended since they seem a bit conflicted about whether only 1 or > 1 chars can be deleted. - The method is called deleteChar and says it updates the measurer in such a case. - It then says that this call is equivalent to creating a new measurer from the text .. presumably meaning the text represented by the iterator. - I am sure that "newParagraph" is expected to be a sub-set of the old text but what stops you from having original text "abcdef" and new text "12345" ? That seems like it neds some doc treatment .. at the least .. have some fun testing that when you replace LTR with RTL text for example. - The code does check to see if the new text is other than one char different .. although it checks only the length .. not the content and if the length is !=1 char different it it is then re-creates from scratch. This seems to suggest that it is expected to support > 1 char deleted and allows for the 1 char case as an optimisation. - A consequence of these previous two points is that - I don't see any "state" at the API level, so the discussions about resetting or losing state are confusing. The internal "state" won't be lost, it'll be re-created. - I am at a loss to understand why after "initAll()" the method needs to go through the pointless exercise of recreating the arrays and calling StyledParagraph.deleteChar(..) Seems to me it can just proceed straight to invalidateComponents() In fact isn't this the bug ? That's why we get AIOB .. because the code assumes "fChars" is the original longer array. On balance I think the method is mis-named and mis-documented in suggesting only a single char is supported. We can't fix the name but we can fix the docs and the exception. This may be the most compatible and most useful fix. - LineBreakMeasurer looks very similar and needs the same treatment as this class - Minor thing to fix : StyledParagraph.deleteChar javadoc seems to have a copy paste error from StyledParagraph.insertChar * Return a StyledParagraph reflecting the insertion of a single character * into the text Should be * Return a StyledParagraph reflecting the deletion of a single character * from the text -phil. On 12/29/2017 03:00 AM, Prahalad Kumar Narayanan wrote: > Hello Everyone > > Good day to you. > > Request your time in reviewing the fix for the bug: > JDK-5064835 TextMeasurer/deleteChar function fails when deleting more than one characters. > > Root Cause: > . The spec clearly mentions that the concerned method is to be used to delete a single character. > . However, the spec does not mention the outcome when the method is used to delete multiple characters (as reported in the bug) > > Solution Approaches: > . Since the spec does not mention the outcome when multiple characters are deleted, the result is left to the implementation. > . The solution can be approached in two perspectives- > 1. Update the spec to explicitly mention the exception that would be thrown in such cases or > 2. Re-initialize the TextMeasurer with the new text as present in the argument of the method. > > Solution: > . I inspected feasibility/ risk of both the approaches and I 'm of the opinion that approach 1. is better. > . Reason is that, with the second approach- > . The re-initialization would reset all text attributes, and state variabes that were set on TextMeasurer (and internal StyledParagraph) object. > . If re-initialization is required, one could create a new TextMeasurer using the modified text rather than invoking deleteChar method. > . Thus in the proposed solution- I 've added a throws clause that explicitly mentions that IllegalArgumentException will be thrown when attempted to delete multiple characters. > > Other Info: > . The fix was tested with existing jtreg test cases- No regressions were seen. > . 2 JCK tests have been found to fail. They are- > . java_awt/Font/TextMeasurer/CharTest (TestCase5) > . java_awt/Font/LineBreakMeasurer/CharTest (TestCase4) > . In both the failures, incorrect arguments are passed to deleteChar method- newParagraph (with multiple chars deleted) & beginIndex (-1) > . While the test case expects index out of bounds exception for -ve index, the code now throws IllegalArgumentsException. > . A minor correction to JCK test will fix the issue. I shall raise a JCK bug once the fix is approved & submitted. > > Kindly review the changes at your convenience & share your feedback: > http://cr.openjdk.java.net/~pnarayanan/5064835/webrev.00/ > > Note: I 've not raised a CSR for this bug yet. > Based on review, I will create the CSR for change to the specification. > > Thank you for your time in review & > Happy New Year > > Prahalad N. From Sergey.Bylokhov at oracle.com Sat Jan 13 03:29:42 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 12 Jan 2018 19:29:42 -0800 Subject: [OpenJDK 2D-Dev] RFR JDK-8191174: PngReader throws IllegalArgumentException because ScanlineStride calculation logic is not proper In-Reply-To: References: <6639d1ae-fa52-4505-af5f-1bf3e114fbe5@default> <4903dfdb-8c64-4a38-95e2-549f26b3ee41@default> <045c7f01-106f-4f01-a661-a82ab15c1b1c@default> <74518345-8ed6-44da-b384-01802c01368c@default> Message-ID: <5403b056-4c44-afbf-81dd-82a2d76510de@oracle.com> Hi, Jay. Can you please confirm that it is not possible to get overflow in: "inputBands * bitDepth"? 1051 int bitsPerRow = Math.multiplyExact((inputBands * bitDepth), passWidth); On 08/01/2018 02:04, Jayathirth D V wrote: > As you have mentioned throwing "Pixel stride times width must be less than or equal to the scanline stride" is not proper in this scenario as image contains proper width as per PNG specification. > Thanks for pointing to Math.multiplyExact() function and it is very beneficial for solving this issue. While calculating bytesPerRow itself we can use Math.multiplyExact() and throw "int overflow" ArithmeticException and it will be wrapped into IIOException because of changes present in https://bugs.openjdk.java.net/browse/JDK-8190332 . > > By doing this we will not have multiple "Caused by" chain and we will be throwing proper exception as per ImageIO specification. > Please find updated webrev for review: > http://cr.openjdk.java.net/~jdv/8191174/webrev.02/ > > Thanks, > Jay > > -----Original Message----- > From: Sergey Bylokhov > Sent: Saturday, January 06, 2018 2:45 PM > To: Prahalad Kumar Narayanan; Jayathirth D V; 2d-dev > Subject: Re: [OpenJDK 2D-Dev] RFR JDK-8191174: PngReader throws IllegalArgumentException because ScanlineStride calculation logic is not proper > > Probably we can use Math.multiplyExact()? The current exception text wrapped a few times "Pixel stride times width must be less than or equal to the scanline stride" is not strictly correct because it is possible that the image itself has correct data, but we cannot handle it because of overflow. > > On 28/12/2017 22:49, Prahalad Kumar Narayanan wrote: >> Hello Jay >> >> Good day to you. >> >> The code changes wrap the IllegalArgumentException in IIOException. >> This approach is better & aligns with how OutOfMemoryError was wrapped to fix JDK-8190332. >> >> The only point that I 'm not sure is- whether we could wrap IllegalArgumentException twice before throwing to the user code. >> >> javax.imageio.IIOException: Error reading PNG image data >> at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.readImage >> at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.read >> at java.desktop/javax.imageio.ImageIO.read >> ... >> Caused by: javax.imageio.IIOException: Caught exception during read: >> at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.decodePass >> at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.decodeImage >> ... >> Caused by: java.lang.IllegalArgumentException: Pixel stride times width must be less than or equal to the scanline stride >> at java.desktop/java.awt.image.PixelInterleavedSampleModel. >> at java.desktop/java.awt.image.Raster.createInterleavedRaster >> at >> java.desktop/com.sun.imageio.plugins.png.PNGImageReader.createRaster >> >> Since there are multiple levels of same exception, programmer could have trouble getting the cause using getCause() method. >> However, Invoking printStackTrace() on the outer most exception object gives complete call stack (as listed above). >> So I think, this should be ok. >> >> I would like to know of others' opinion too. >> >> Thank you >> Have a good day >> >> Prahalad N. >> >> >> -----Original Message----- >> From: Jayathirth D V >> Sent: Thursday, December 28, 2017 3:43 PM >> To: Prahalad Kumar Narayanan; 2d-dev >> Subject: RE: [OpenJDK 2D-Dev] RFR JDK-8191174: PngReader throws >> IllegalArgumentException because ScanlineStride calculation logic is >> not proper >> >> Hi Prahalad, >> >> Thanks for your valuable inputs. >> >> Even though the fix resolves the issue for the particular test case we have it will not solve the buffer overflow problem as you have mentioned in highest limit case or many other cases where the computed value is very high. >> >> Also we cannot change datatype of bytesPerRow/eltsPerRow as they are used in many passed to many other Raster and Stream API's. The best approach to resolve this issue would be to wrap the Exception that we are getting while creating Raster/SampleModel into an IIOException as we have done in https://bugs.openjdk.java.net/browse/JDK-8190332 . By doing this we will abide by specification and also we will have complete stack of why we got the exception so that it can be debugged properly in future. >> >> Please find updated webrev for review: >> http://cr.openjdk.java.net/~jdv/8191174/webrev.01/ >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Prahalad Kumar Narayanan >> Sent: Tuesday, December 19, 2017 3:08 PM >> To: Jayathirth D V; 2d-dev >> Subject: RE: [OpenJDK 2D-Dev] RFR JDK-8191174: PngReader throws >> IllegalArgumentException because ScanlineStride calculation logic is >> not proper >> >> >> Hello Jay >> >> Good day to you. >> >> I don't think it's possible to fix this issue despite having intermediate " long " variable to hold intermediate bits per pixel. >> Here is a simple math that considers the worst case scenario with max values: >> >> . As per the PNG specification, the maximum permissible width, number of bands, bit-depth are as follows- >> max_width : (2 ^ 31) - 1 = 2147483647 >> max_input_bands = 4 >> max_bit_depth = 16 (2 Bytes) >> >> . As per the logic proposed in the fix, the intermediate bits per row would fit into a "long" variable but bytes per pixel would not fit into "int" variable. >> // Fits into "long" data type >> max_bits_per_row = max_width * max_input_bands * max_bit_depth >> = 2147483647 x 4 x 16 >> = 137438953408 >> >> // Does not fit into "int" data type >> max_bytes_per_row = max_bits_per_row + 7 / 8 >> = 17179869176 >> = (0x 3FFFFFFF8 - >> Goes beyond 4B boundary) >> >> // Upon division by 2 for 16-bit images >> max_elts_per_row = max_bytes_per_row / 2 >> = 8589934588 >> = (0x 1FFFFFFFC - Goes >> beyond 4B boundary) >> >> . If we intend to store bytes per row (and eltsPerRow which is scanline stride) in a "long" variable, the same cannot be sent to Raster APIs because the APIs accept "int" type for scanline stride in arguments list. >> Going by the Raster APIs used in PNGImageReader, a proper fix would require changes to its APIs as well to handle such large scanline stride values. >> >> Thank you >> Have a good day >> >> Prahalad N. >> >> ----- Original Message ----- >> From: Jayathirth D V >> Sent: Thursday, December 14, 2017 1:48 PM >> To: 2d-dev >> Subject: [OpenJDK 2D-Dev] RFR JDK-8191174: PngReader throws >> IllegalArgumentException because ScanlineStride calculation logic is >> not proper >> >> Hello All, >> >> Please review the following fix in JDK : >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-8191174 >> Webrev : http://cr.openjdk.java.net/~jdv/8191174/webrev.00/ >> >> Issue : When we try to read PNG image with large width we throw undocumented IllegalArgumentException with message "Pixel stride times width must be less than or equal to the scanline stride". >> >> Exception in thread "main" java.lang.IllegalArgumentException: Pixel >> stride times width must be less than or equal to the scanline stride >> ??????????????? at >> java.desktop/java.awt.image.PixelInterleavedSampleModel.(PixelIn >> terleavedSampleModel.java:101) >> ??????????????? at >> java.desktop/java.awt.image.Raster.createInterleavedRaster(Raster.java >> :642) >> ??????????????? at >> java.desktop/com.sun.imageio.plugins.png.PNGImageReader.createRaster(P >> NGImageReader.java:974) >> ??????????????? at >> java.desktop/com.sun.imageio.plugins.png.PNGImageReader.decodePass(PNG >> ImageReader.java:1099) >> ??????????????? at >> java.desktop/com.sun.imageio.plugins.png.PNGImageReader.decodeImage(PN >> GImageReader.java:1295) >> ??????????????? at >> java.desktop/com.sun.imageio.plugins.png.PNGImageReader.readImage(PNGI >> mageReader.java:1420) >> ??????????????? at >> java.desktop/com.sun.imageio.plugins.png.PNGImageReader.read(PNGImageR >> eader.java:1699) >> ??????????????? at >> java.desktop/javax.imageio.ImageIO.read(ImageIO.java:1468) >> ??????????????? at >> java.desktop/javax.imageio.ImageIO.read(ImageIO.java:1363) >> ??????????????? at >> PngReaderLargeWidthStrideTest.main(PngReaderLargeWidthStrideTest.java: >> 50) >> >> Root cause : We use large width present in IHDR and calculate elements per row which is passed as scanlinestride for creating the required raster and its corresponding sample model. ?When the call reaches creation of PixelInterleavedSampleModel it checks the condition of (pixelStride * w) > scanlineStride. Since in our case we pass this condition it throws IllegalArgumentException. We have invalid scanlineStride value because when we calculate elements per row/bytes per row value in PNGImageReader the integer variable buffer is overflowed and we maintain invalid value for bytesPerRow. >> >> Solution : We can maintain the intermediate bitsPerRow value in long datatype and calculate bytesPerRow using the long value and then typecast it to int bytesPerRow variable. By doing this we will maintain the required scanlineStride/eltsPerRow value properly. After this solution we will throw proper IIOException because of changes present in JDK-8190332 and not the undocumented IllegalArgumentException. >> >> Thanks, >> Jay >> > > > -- > Best regards, Sergey. > -- Best regards, Sergey. From jayathirth.d.v at oracle.com Mon Jan 15 07:08:30 2018 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Sun, 14 Jan 2018 23:08:30 -0800 (PST) Subject: [OpenJDK 2D-Dev] RFR JDK-8191174: PngReader throws IllegalArgumentException because ScanlineStride calculation logic is not proper In-Reply-To: <5403b056-4c44-afbf-81dd-82a2d76510de@oracle.com> References: <6639d1ae-fa52-4505-af5f-1bf3e114fbe5@default> <4903dfdb-8c64-4a38-95e2-549f26b3ee41@default> <045c7f01-106f-4f01-a661-a82ab15c1b1c@default> <74518345-8ed6-44da-b384-01802c01368c@default> <5403b056-4c44-afbf-81dd-82a2d76510de@oracle.com> Message-ID: Hello Sergey, Thanks for reviewing the changes. The maximum value of inputBands & bitDepth can be 4 & 16. Also in readHeader() we verify the values present in inputBands & bitDepth and if they are not in required bounds we throw IIOException. So (inputBands * bitDepth) will not cause overflow. Also I noticed that we need to use Math.multiplyExact() in skipPass() function too where we have same calculation. So I have updated the code to reflect the same. Please review the updated webrev: http://cr.openjdk.java.net/~jdv/8191174/webrev.03/ Thanks, Jay -----Original Message----- From: Sergey Bylokhov Sent: Saturday, January 13, 2018 9:00 AM To: Jayathirth D V; 2d-dev Subject: Re: [OpenJDK 2D-Dev] RFR JDK-8191174: PngReader throws IllegalArgumentException because ScanlineStride calculation logic is not proper Hi, Jay. Can you please confirm that it is not possible to get overflow in: "inputBands * bitDepth"? 1051 int bitsPerRow = Math.multiplyExact((inputBands * bitDepth), passWidth); On 08/01/2018 02:04, Jayathirth D V wrote: > As you have mentioned throwing "Pixel stride times width must be less than or equal to the scanline stride" is not proper in this scenario as image contains proper width as per PNG specification. > Thanks for pointing to Math.multiplyExact() function and it is very beneficial for solving this issue. While calculating bytesPerRow itself we can use Math.multiplyExact() and throw "int overflow" ArithmeticException and it will be wrapped into IIOException because of changes present in https://bugs.openjdk.java.net/browse/JDK-8190332 . > > By doing this we will not have multiple "Caused by" chain and we will be throwing proper exception as per ImageIO specification. > Please find updated webrev for review: > http://cr.openjdk.java.net/~jdv/8191174/webrev.02/ > > Thanks, > Jay > > -----Original Message----- > From: Sergey Bylokhov > Sent: Saturday, January 06, 2018 2:45 PM > To: Prahalad Kumar Narayanan; Jayathirth D V; 2d-dev > Subject: Re: [OpenJDK 2D-Dev] RFR JDK-8191174: PngReader throws > IllegalArgumentException because ScanlineStride calculation logic is > not proper > > Probably we can use Math.multiplyExact()? The current exception text wrapped a few times "Pixel stride times width must be less than or equal to the scanline stride" is not strictly correct because it is possible that the image itself has correct data, but we cannot handle it because of overflow. > > On 28/12/2017 22:49, Prahalad Kumar Narayanan wrote: >> Hello Jay >> >> Good day to you. >> >> The code changes wrap the IllegalArgumentException in IIOException. >> This approach is better & aligns with how OutOfMemoryError was wrapped to fix JDK-8190332. >> >> The only point that I 'm not sure is- whether we could wrap IllegalArgumentException twice before throwing to the user code. >> >> javax.imageio.IIOException: Error reading PNG image data >> at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.readImage >> at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.read >> at java.desktop/javax.imageio.ImageIO.read >> ... >> Caused by: javax.imageio.IIOException: Caught exception during read: >> at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.decodePass >> at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.decodeImage >> ... >> Caused by: java.lang.IllegalArgumentException: Pixel stride times width must be less than or equal to the scanline stride >> at java.desktop/java.awt.image.PixelInterleavedSampleModel. >> at java.desktop/java.awt.image.Raster.createInterleavedRaster >> at >> java.desktop/com.sun.imageio.plugins.png.PNGImageReader.createRaster >> >> Since there are multiple levels of same exception, programmer could have trouble getting the cause using getCause() method. >> However, Invoking printStackTrace() on the outer most exception object gives complete call stack (as listed above). >> So I think, this should be ok. >> >> I would like to know of others' opinion too. >> >> Thank you >> Have a good day >> >> Prahalad N. >> >> >> -----Original Message----- >> From: Jayathirth D V >> Sent: Thursday, December 28, 2017 3:43 PM >> To: Prahalad Kumar Narayanan; 2d-dev >> Subject: RE: [OpenJDK 2D-Dev] RFR JDK-8191174: PngReader throws >> IllegalArgumentException because ScanlineStride calculation logic is >> not proper >> >> Hi Prahalad, >> >> Thanks for your valuable inputs. >> >> Even though the fix resolves the issue for the particular test case we have it will not solve the buffer overflow problem as you have mentioned in highest limit case or many other cases where the computed value is very high. >> >> Also we cannot change datatype of bytesPerRow/eltsPerRow as they are used in many passed to many other Raster and Stream API's. The best approach to resolve this issue would be to wrap the Exception that we are getting while creating Raster/SampleModel into an IIOException as we have done in https://bugs.openjdk.java.net/browse/JDK-8190332 . By doing this we will abide by specification and also we will have complete stack of why we got the exception so that it can be debugged properly in future. >> >> Please find updated webrev for review: >> http://cr.openjdk.java.net/~jdv/8191174/webrev.01/ >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Prahalad Kumar Narayanan >> Sent: Tuesday, December 19, 2017 3:08 PM >> To: Jayathirth D V; 2d-dev >> Subject: RE: [OpenJDK 2D-Dev] RFR JDK-8191174: PngReader throws >> IllegalArgumentException because ScanlineStride calculation logic is >> not proper >> >> >> Hello Jay >> >> Good day to you. >> >> I don't think it's possible to fix this issue despite having intermediate " long " variable to hold intermediate bits per pixel. >> Here is a simple math that considers the worst case scenario with max values: >> >> . As per the PNG specification, the maximum permissible width, number of bands, bit-depth are as follows- >> max_width : (2 ^ 31) - 1 = 2147483647 >> max_input_bands = 4 >> max_bit_depth = 16 (2 Bytes) >> >> . As per the logic proposed in the fix, the intermediate bits per row would fit into a "long" variable but bytes per pixel would not fit into "int" variable. >> // Fits into "long" data type >> max_bits_per_row = max_width * max_input_bands * max_bit_depth >> = 2147483647 x 4 x 16 >> = 137438953408 >> >> // Does not fit into "int" data type >> max_bytes_per_row = max_bits_per_row + 7 / 8 >> = 17179869176 >> = (0x 3FFFFFFF8 - >> Goes beyond 4B boundary) >> >> // Upon division by 2 for 16-bit images >> max_elts_per_row = max_bytes_per_row / 2 >> = 8589934588 >> = (0x 1FFFFFFFC - Goes >> beyond 4B boundary) >> >> . If we intend to store bytes per row (and eltsPerRow which is scanline stride) in a "long" variable, the same cannot be sent to Raster APIs because the APIs accept "int" type for scanline stride in arguments list. >> Going by the Raster APIs used in PNGImageReader, a proper fix would require changes to its APIs as well to handle such large scanline stride values. >> >> Thank you >> Have a good day >> >> Prahalad N. >> >> ----- Original Message ----- >> From: Jayathirth D V >> Sent: Thursday, December 14, 2017 1:48 PM >> To: 2d-dev >> Subject: [OpenJDK 2D-Dev] RFR JDK-8191174: PngReader throws >> IllegalArgumentException because ScanlineStride calculation logic is >> not proper >> >> Hello All, >> >> Please review the following fix in JDK : >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-8191174 >> Webrev : http://cr.openjdk.java.net/~jdv/8191174/webrev.00/ >> >> Issue : When we try to read PNG image with large width we throw undocumented IllegalArgumentException with message "Pixel stride times width must be less than or equal to the scanline stride". >> >> Exception in thread "main" java.lang.IllegalArgumentException: Pixel >> stride times width must be less than or equal to the scanline stride >> ??????????????? at >> java.desktop/java.awt.image.PixelInterleavedSampleModel.(PixelI >> n >> terleavedSampleModel.java:101) >> ??????????????? at >> java.desktop/java.awt.image.Raster.createInterleavedRaster(Raster.jav >> a >> :642) >> ??????????????? at >> java.desktop/com.sun.imageio.plugins.png.PNGImageReader.createRaster( >> P >> NGImageReader.java:974) >> ??????????????? at >> java.desktop/com.sun.imageio.plugins.png.PNGImageReader.decodePass(PN >> G >> ImageReader.java:1099) >> ??????????????? at >> java.desktop/com.sun.imageio.plugins.png.PNGImageReader.decodeImage(P >> N >> GImageReader.java:1295) >> ??????????????? at >> java.desktop/com.sun.imageio.plugins.png.PNGImageReader.readImage(PNG >> I >> mageReader.java:1420) >> ??????????????? at >> java.desktop/com.sun.imageio.plugins.png.PNGImageReader.read(PNGImage >> R >> eader.java:1699) >> ??????????????? at >> java.desktop/javax.imageio.ImageIO.read(ImageIO.java:1468) >> ??????????????? at >> java.desktop/javax.imageio.ImageIO.read(ImageIO.java:1363) >> ??????????????? at >> PngReaderLargeWidthStrideTest.main(PngReaderLargeWidthStrideTest.java: >> 50) >> >> Root cause : We use large width present in IHDR and calculate elements per row which is passed as scanlinestride for creating the required raster and its corresponding sample model. ?When the call reaches creation of PixelInterleavedSampleModel it checks the condition of (pixelStride * w) > scanlineStride. Since in our case we pass this condition it throws IllegalArgumentException. We have invalid scanlineStride value because when we calculate elements per row/bytes per row value in PNGImageReader the integer variable buffer is overflowed and we maintain invalid value for bytesPerRow. >> >> Solution : We can maintain the intermediate bitsPerRow value in long datatype and calculate bytesPerRow using the long value and then typecast it to int bytesPerRow variable. By doing this we will maintain the required scanlineStride/eltsPerRow value properly. After this solution we will throw proper IIOException because of changes present in JDK-8190332 and not the undocumented IllegalArgumentException. >> >> Thanks, >> Jay >> > > > -- > Best regards, Sergey. > -- Best regards, Sergey. From prahalad.kumar.narayanan at oracle.com Tue Jan 16 02:56:59 2018 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Mon, 15 Jan 2018 18:56:59 -0800 (PST) Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8176795: Wrong color drawn when painting translucent colors on volatile images using XRender. In-Reply-To: <294c9548-0095-4b68-bb6b-1c8d0eba2cc1@default> References: <294c9548-0095-4b68-bb6b-1c8d0eba2cc1@default> Message-ID: <78bf6d21-bc93-4c79-8f52-ecb690c5381a@default> Hello Jay > After that I listed call hierarchy to XRColor.setColorValues(int, boolean) and found that after my fix at all the places we are passing second argument as true and it is resulting in dead/unused code in XRColor.setColorValues(int, boolean) . I understand your point that the snippet of code is presently not being used by XRender pipeline. . But I 'm not convinced of removing the logic for reasons that I put in previous review. . If you believe, the code should be removed, my suggestion would be to take this code removal as a separate bug. . This way the revert operation to bring the logic back is easier. > In the test case present in this bug we are creating a Compatible Volatile Image from a GraphicsConfiguration so I think there is no need to validate the compatibility as GC . Thanks for clarification. Your approach is right. On a lighter note: This being an open forum, there is a possibility that other reviewers might approve the change in its current version. Hence for the benefit of engineer who has proposed the fix, I didn't respond to your email until now. Thanks Have a good day Prahalad N. -----Original Message----- From: Jayathirth D V Sent: Thursday, December 14, 2017 6:49 PM To: Prahalad Kumar Narayanan; Philip Race; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [10] RFR JDK-8176795: Wrong color drawn when painting translucent colors on volatile images using XRender. Hello Prahalad, Thanks for your inputs. Regarding code change mentioned by you in source: Initially I also just replaced xrCol.setColorValues(pixelVal, false) with xrCol.setColorValues(pixelVal, true) in XRSolidSrcPict.java to fix the issue. After that I listed call hierarchy to XRColor.setColorValues(int, boolean) and found that after my fix at all the places we are passing second argument as true and it is resulting in dead/unused code in XRColor.setColorValues(int, boolean). Dead code in XRColor.setColorValues(int, boolean) which will be never reached: if (!pre) { double alphaMult = XRUtils.XFixedToDouble(alpha); this.red = (int) (red * alphaMult); this.green = (int) (green * alphaMult); this.blue = (int) (blue * alphaMult); } Before removing this dead code for review I researched and found that it is always advised to remove the dead/unused code(https://www.infoq.com/news/2017/02/dead-code , https://stackoverflow.com/questions/15699995/why-unused-code-should-be-deleted ). Also if we don't remove the dead code and just change second argument passed in setColorValues() for our fix any static analyzer tool will show it as a bug/unreachable code. >From future use case perspective we have version control to get back the logic so it should not be a problem. So I think it's better to clean up the unused code even if we need to do small changes like removing the second argument in other files. Regarding code change mentioned by you in test case: I think you are referring to VolatileImage.validate(GraphicsConfiguration) and checking whether it returns VolatileImage.IMAGE_INCOMPATIBLE. In the test case present in this bug we are creating a Compatible Volatile Image from a GraphicsConfiguration so I think there is no need to validate the compatibility as GC. createCompatibleVolatileImage(int, int ) mentions that it " Returns a VolatileImage with a data layout and color model compatible with this GraphicsConfiguration ". If I am missing something regarding the test case change you have mentioned please guide me. Regards, Jay -----Original Message----- From: Prahalad Kumar Narayanan Sent: Thursday, December 14, 2017 5:19 PM To: Philip Race; Jayathirth D V; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [10] RFR JDK-8176795: Wrong color drawn when painting translucent colors on volatile images using XRender. Hello Jay I looked into the changes. Here are my views. > X Rendering extension expects pre-multiplied alpha color values, so we need to convert the non-premultiplied alpha color values to pre-multiplied alpha color values before give pixel value to XRender for drawing. > The main problem is we do this operation of conversion twice . Your observation is correct. This is a good find. . The double conversion occurs because of mis-match between two objects - . XRCompositeManager that passes pre-multiplied alpha color to prepare XRSolidSrcPict and . XRSolidSrcPict that expects a "non pre-multiplied" alpha color in its prepareSrcPict method. > Also this logic of non-pre to pre color conversion at XRender was only used when source is Solid color and not Texture/Gradient. > So I have completely removed this logic itself as it not needed anywhere else. . In the proposed fix, you have removed a convenience logic in XRColor.java and modified one (XRColor) method signature as well. . In my view, this change is not required at all. Reasons are- . Though the convenience logic isn't used presently, it could definitely come handy in future whenever a need arises. . The change to method's signature has resulted in recursive changes in many other files as well. . The bug and the fix are not related to XRColor object in general. Combining the above observation, the fix would be to correct 2nd argument of below mentioned line from "false" to "true". Thus retain the convenience logic in XRColor.java as well. File: XRSolidSrcPict.java line 50 xrCol.setColorValues(pixelVal, false); // Change false to true Btw, the test case involves drawing on a VolatileImage & getting its snapshot. But it doesn't check if the created volatile image is valid for a particular Graphics configuration before invoking any drawing operation. You could refer to one of the existing test cases and correct the test file. Thank you Have a good day Prahalad N. ----- Original Message ----- From: Phil Race Sent: Tuesday, December 12, 2017 12:15 AM To: Jayathirth D V; 2d-dev Subject: Re: [OpenJDK 2D-Dev] [10] RFR JDK-8176795: Wrong color drawn when painting translucent colors on volatile images using XRender. The explanation sounds reasonable, although I'd like to give Clemens a chance to review this. -phil. On 12/07/2017 07:16 AM, Jayathirth D V wrote: Hello All, ? Please review the following fix in JDK10 : ? Bug : https://bugs.openjdk.java.net/browse/JDK-8176795 Webrev : http://cr.openjdk.java.net/~jdv/8176795/webrev.00/ ? Issue : When we draw translucent color over an opaque color in Unix from JDK 8 we get different color after composition compared to any other platform. ? Root cause : From JDK 8, X Rendering extension is enabled in Unix and we see this problem only when we use XRender in Unix if we use GLX or ?X11 we don't see any issue. ?Also X Rendering extension expects pre-multiplied alpha color values, so we need to convert the non-premultiplied alpha color values to pre-multiplied alpha color values before give pixel value to XRender for drawing. The main problem is we do this operation of conversion twice: 1) When we call Graphics2D.setColor() it uses ArgbPre PixelConverter based on SurfaceData(here it is XRenderPixMap ArgbPre surface) and converts the color to pre-multiplied values. 2) When we call Graphics2D.fillRect() internally before we compose the destination(opaque color) and source(translucent color) we prepare source render rectangle for X Render extension. Here again we convert the already converted color values to premultiplied values. ? Solution : There is no need for us to do non-pre to pre color conversion again at XRender level so it should be removed. Also this logic of non-pre to pre color conversion at XRender was only used when source is Solid color and not Texture/Gradient. So I have completely removed this logic itself as it not needed anywhere else. ? Thanks, Jay ? From jayathirth.d.v at oracle.com Tue Jan 16 06:50:51 2018 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 15 Jan 2018 22:50:51 -0800 (PST) Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8176795: Wrong color drawn when painting translucent colors on volatile images using XRender. In-Reply-To: <78bf6d21-bc93-4c79-8f52-ecb690c5381a@default> References: <294c9548-0095-4b68-bb6b-1c8d0eba2cc1@default> <78bf6d21-bc93-4c79-8f52-ecb690c5381a@default> Message-ID: <85479031-dc5f-4d6f-b496-662b13604cd1@default> Hi Prahalad, Thanks for your inputs. I have no concerns about providing overall solution(Fix + Dead code removal) in two separate bugs. I have removed the code corresponding to dead code removal and created a separate bug https://bugs.openjdk.java.net/browse/JDK-8195131 in which dead code will be removed. Please review the updated webrev: http://cr.openjdk.java.net/~jdv/8176795/webrev.01/ Thanks, Jay -----Original Message----- From: Prahalad Kumar Narayanan Sent: Tuesday, January 16, 2018 8:27 AM To: Jayathirth D V; Philip Race; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [10] RFR JDK-8176795: Wrong color drawn when painting translucent colors on volatile images using XRender. Hello Jay > After that I listed call hierarchy to XRColor.setColorValues(int, boolean) and found that after my fix at all the places we are passing second argument as true and it is resulting in dead/unused code in XRColor.setColorValues(int, boolean) . I understand your point that the snippet of code is presently not being used by XRender pipeline. . But I 'm not convinced of removing the logic for reasons that I put in previous review. . If you believe, the code should be removed, my suggestion would be to take this code removal as a separate bug. . This way the revert operation to bring the logic back is easier. > In the test case present in this bug we are creating a Compatible Volatile Image from a GraphicsConfiguration so I think there is no need to validate the compatibility as GC . Thanks for clarification. Your approach is right. On a lighter note: This being an open forum, there is a possibility that other reviewers might approve the change in its current version. Hence for the benefit of engineer who has proposed the fix, I didn't respond to your email until now. Thanks Have a good day Prahalad N. -----Original Message----- From: Jayathirth D V Sent: Thursday, December 14, 2017 6:49 PM To: Prahalad Kumar Narayanan; Philip Race; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [10] RFR JDK-8176795: Wrong color drawn when painting translucent colors on volatile images using XRender. Hello Prahalad, Thanks for your inputs. Regarding code change mentioned by you in source: Initially I also just replaced xrCol.setColorValues(pixelVal, false) with xrCol.setColorValues(pixelVal, true) in XRSolidSrcPict.java to fix the issue. After that I listed call hierarchy to XRColor.setColorValues(int, boolean) and found that after my fix at all the places we are passing second argument as true and it is resulting in dead/unused code in XRColor.setColorValues(int, boolean). Dead code in XRColor.setColorValues(int, boolean) which will be never reached: if (!pre) { double alphaMult = XRUtils.XFixedToDouble(alpha); this.red = (int) (red * alphaMult); this.green = (int) (green * alphaMult); this.blue = (int) (blue * alphaMult); } Before removing this dead code for review I researched and found that it is always advised to remove the dead/unused code(https://www.infoq.com/news/2017/02/dead-code , https://stackoverflow.com/questions/15699995/why-unused-code-should-be-deleted ). Also if we don't remove the dead code and just change second argument passed in setColorValues() for our fix any static analyzer tool will show it as a bug/unreachable code. >From future use case perspective we have version control to get back the logic so it should not be a problem. So I think it's better to clean up the unused code even if we need to do small changes like removing the second argument in other files. Regarding code change mentioned by you in test case: I think you are referring to VolatileImage.validate(GraphicsConfiguration) and checking whether it returns VolatileImage.IMAGE_INCOMPATIBLE. In the test case present in this bug we are creating a Compatible Volatile Image from a GraphicsConfiguration so I think there is no need to validate the compatibility as GC. createCompatibleVolatileImage(int, int ) mentions that it " Returns a VolatileImage with a data layout and color model compatible with this GraphicsConfiguration ". If I am missing something regarding the test case change you have mentioned please guide me. Regards, Jay -----Original Message----- From: Prahalad Kumar Narayanan Sent: Thursday, December 14, 2017 5:19 PM To: Philip Race; Jayathirth D V; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [10] RFR JDK-8176795: Wrong color drawn when painting translucent colors on volatile images using XRender. Hello Jay I looked into the changes. Here are my views. > X Rendering extension expects pre-multiplied alpha color values, so we need to convert the non-premultiplied alpha color values to pre-multiplied alpha color values before give pixel value to XRender for drawing. > The main problem is we do this operation of conversion twice . Your observation is correct. This is a good find. . The double conversion occurs because of mis-match between two objects - . XRCompositeManager that passes pre-multiplied alpha color to prepare XRSolidSrcPict and . XRSolidSrcPict that expects a "non pre-multiplied" alpha color in its prepareSrcPict method. > Also this logic of non-pre to pre color conversion at XRender was only used when source is Solid color and not Texture/Gradient. > So I have completely removed this logic itself as it not needed anywhere else. . In the proposed fix, you have removed a convenience logic in XRColor.java and modified one (XRColor) method signature as well. . In my view, this change is not required at all. Reasons are- . Though the convenience logic isn't used presently, it could definitely come handy in future whenever a need arises. . The change to method's signature has resulted in recursive changes in many other files as well. . The bug and the fix are not related to XRColor object in general. Combining the above observation, the fix would be to correct 2nd argument of below mentioned line from "false" to "true". Thus retain the convenience logic in XRColor.java as well. File: XRSolidSrcPict.java line 50 xrCol.setColorValues(pixelVal, false); // Change false to true Btw, the test case involves drawing on a VolatileImage & getting its snapshot. But it doesn't check if the created volatile image is valid for a particular Graphics configuration before invoking any drawing operation. You could refer to one of the existing test cases and correct the test file. Thank you Have a good day Prahalad N. ----- Original Message ----- From: Phil Race Sent: Tuesday, December 12, 2017 12:15 AM To: Jayathirth D V; 2d-dev Subject: Re: [OpenJDK 2D-Dev] [10] RFR JDK-8176795: Wrong color drawn when painting translucent colors on volatile images using XRender. The explanation sounds reasonable, although I'd like to give Clemens a chance to review this. -phil. On 12/07/2017 07:16 AM, Jayathirth D V wrote: Hello All, ? Please review the following fix in JDK10 : ? Bug : https://bugs.openjdk.java.net/browse/JDK-8176795 Webrev : http://cr.openjdk.java.net/~jdv/8176795/webrev.00/ ? Issue : When we draw translucent color over an opaque color in Unix from JDK 8 we get different color after composition compared to any other platform. ? Root cause : From JDK 8, X Rendering extension is enabled in Unix and we see this problem only when we use XRender in Unix if we use GLX or ?X11 we don't see any issue. ?Also X Rendering extension expects pre-multiplied alpha color values, so we need to convert the non-premultiplied alpha color values to pre-multiplied alpha color values before give pixel value to XRender for drawing. The main problem is we do this operation of conversion twice: 1) When we call Graphics2D.setColor() it uses ArgbPre PixelConverter based on SurfaceData(here it is XRenderPixMap ArgbPre surface) and converts the color to pre-multiplied values. 2) When we call Graphics2D.fillRect() internally before we compose the destination(opaque color) and source(translucent color) we prepare source render rectangle for X Render extension. Here again we convert the already converted color values to premultiplied values. ? Solution : There is no need for us to do non-pre to pre color conversion again at XRender level so it should be removed. Also this logic of non-pre to pre color conversion at XRender was only used when source is Solid color and not Texture/Gradient. So I have completely removed this logic itself as it not needed anywhere else. ? Thanks, Jay ? From prahalad.kumar.narayanan at oracle.com Tue Jan 16 06:57:19 2018 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Mon, 15 Jan 2018 22:57:19 -0800 (PST) Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8176795: Wrong color drawn when painting translucent colors on volatile images using XRender. In-Reply-To: <85479031-dc5f-4d6f-b496-662b13604cd1@default> References: <294c9548-0095-4b68-bb6b-1c8d0eba2cc1@default> <78bf6d21-bc93-4c79-8f52-ecb690c5381a@default> <85479031-dc5f-4d6f-b496-662b13604cd1@default> Message-ID: <2f2b14a1-eecb-4477-bc17-1ae93e392d88@default> Hello Jay The code change to fix the bug is good. Thanks Have a good day Prahalad N. -----Original Message----- From: Jayathirth D V Sent: Tuesday, January 16, 2018 12:21 PM To: Prahalad Kumar Narayanan; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [10] RFR JDK-8176795: Wrong color drawn when painting translucent colors on volatile images using XRender. Hi Prahalad, Thanks for your inputs. I have no concerns about providing overall solution(Fix + Dead code removal) in two separate bugs. I have removed the code corresponding to dead code removal and created a separate bug https://bugs.openjdk.java.net/browse/JDK-8195131 in which dead code will be removed. Please review the updated webrev: http://cr.openjdk.java.net/~jdv/8176795/webrev.01/ Thanks, Jay -----Original Message----- From: Prahalad Kumar Narayanan Sent: Tuesday, January 16, 2018 8:27 AM To: Jayathirth D V; Philip Race; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [10] RFR JDK-8176795: Wrong color drawn when painting translucent colors on volatile images using XRender. Hello Jay > After that I listed call hierarchy to XRColor.setColorValues(int, boolean) and found that after my fix at all the places we are passing second argument as true and it is resulting in dead/unused code in XRColor.setColorValues(int, boolean) . I understand your point that the snippet of code is presently not being used by XRender pipeline. . But I 'm not convinced of removing the logic for reasons that I put in previous review. . If you believe, the code should be removed, my suggestion would be to take this code removal as a separate bug. . This way the revert operation to bring the logic back is easier. > In the test case present in this bug we are creating a Compatible Volatile Image from a GraphicsConfiguration so I think there is no need to validate the compatibility as GC . Thanks for clarification. Your approach is right. On a lighter note: This being an open forum, there is a possibility that other reviewers might approve the change in its current version. Hence for the benefit of engineer who has proposed the fix, I didn't respond to your email until now. Thanks Have a good day Prahalad N. -----Original Message----- From: Jayathirth D V Sent: Thursday, December 14, 2017 6:49 PM To: Prahalad Kumar Narayanan; Philip Race; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [10] RFR JDK-8176795: Wrong color drawn when painting translucent colors on volatile images using XRender. Hello Prahalad, Thanks for your inputs. Regarding code change mentioned by you in source: Initially I also just replaced xrCol.setColorValues(pixelVal, false) with xrCol.setColorValues(pixelVal, true) in XRSolidSrcPict.java to fix the issue. After that I listed call hierarchy to XRColor.setColorValues(int, boolean) and found that after my fix at all the places we are passing second argument as true and it is resulting in dead/unused code in XRColor.setColorValues(int, boolean). Dead code in XRColor.setColorValues(int, boolean) which will be never reached: if (!pre) { double alphaMult = XRUtils.XFixedToDouble(alpha); this.red = (int) (red * alphaMult); this.green = (int) (green * alphaMult); this.blue = (int) (blue * alphaMult); } Before removing this dead code for review I researched and found that it is always advised to remove the dead/unused code(https://www.infoq.com/news/2017/02/dead-code , https://stackoverflow.com/questions/15699995/why-unused-code-should-be-deleted ). Also if we don't remove the dead code and just change second argument passed in setColorValues() for our fix any static analyzer tool will show it as a bug/unreachable code. >From future use case perspective we have version control to get back the logic so it should not be a problem. So I think it's better to clean up the unused code even if we need to do small changes like removing the second argument in other files. Regarding code change mentioned by you in test case: I think you are referring to VolatileImage.validate(GraphicsConfiguration) and checking whether it returns VolatileImage.IMAGE_INCOMPATIBLE. In the test case present in this bug we are creating a Compatible Volatile Image from a GraphicsConfiguration so I think there is no need to validate the compatibility as GC. createCompatibleVolatileImage(int, int ) mentions that it " Returns a VolatileImage with a data layout and color model compatible with this GraphicsConfiguration ". If I am missing something regarding the test case change you have mentioned please guide me. Regards, Jay -----Original Message----- From: Prahalad Kumar Narayanan Sent: Thursday, December 14, 2017 5:19 PM To: Philip Race; Jayathirth D V; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [10] RFR JDK-8176795: Wrong color drawn when painting translucent colors on volatile images using XRender. Hello Jay I looked into the changes. Here are my views. > X Rendering extension expects pre-multiplied alpha color values, so we need to convert the non-premultiplied alpha color values to pre-multiplied alpha color values before give pixel value to XRender for drawing. > The main problem is we do this operation of conversion twice . Your observation is correct. This is a good find. . The double conversion occurs because of mis-match between two objects - . XRCompositeManager that passes pre-multiplied alpha color to prepare XRSolidSrcPict and . XRSolidSrcPict that expects a "non pre-multiplied" alpha color in its prepareSrcPict method. > Also this logic of non-pre to pre color conversion at XRender was only used when source is Solid color and not Texture/Gradient. > So I have completely removed this logic itself as it not needed anywhere else. . In the proposed fix, you have removed a convenience logic in XRColor.java and modified one (XRColor) method signature as well. . In my view, this change is not required at all. Reasons are- . Though the convenience logic isn't used presently, it could definitely come handy in future whenever a need arises. . The change to method's signature has resulted in recursive changes in many other files as well. . The bug and the fix are not related to XRColor object in general. Combining the above observation, the fix would be to correct 2nd argument of below mentioned line from "false" to "true". Thus retain the convenience logic in XRColor.java as well. File: XRSolidSrcPict.java line 50 xrCol.setColorValues(pixelVal, false); // Change false to true Btw, the test case involves drawing on a VolatileImage & getting its snapshot. But it doesn't check if the created volatile image is valid for a particular Graphics configuration before invoking any drawing operation. You could refer to one of the existing test cases and correct the test file. Thank you Have a good day Prahalad N. ----- Original Message ----- From: Phil Race Sent: Tuesday, December 12, 2017 12:15 AM To: Jayathirth D V; 2d-dev Subject: Re: [OpenJDK 2D-Dev] [10] RFR JDK-8176795: Wrong color drawn when painting translucent colors on volatile images using XRender. The explanation sounds reasonable, although I'd like to give Clemens a chance to review this. -phil. On 12/07/2017 07:16 AM, Jayathirth D V wrote: Hello All, ? Please review the following fix in JDK10 : ? Bug : https://bugs.openjdk.java.net/browse/JDK-8176795 Webrev : http://cr.openjdk.java.net/~jdv/8176795/webrev.00/ ? Issue : When we draw translucent color over an opaque color in Unix from JDK 8 we get different color after composition compared to any other platform. ? Root cause : From JDK 8, X Rendering extension is enabled in Unix and we see this problem only when we use XRender in Unix if we use GLX or ?X11 we don't see any issue. ?Also X Rendering extension expects pre-multiplied alpha color values, so we need to convert the non-premultiplied alpha color values to pre-multiplied alpha color values before give pixel value to XRender for drawing. The main problem is we do this operation of conversion twice: 1) When we call Graphics2D.setColor() it uses ArgbPre PixelConverter based on SurfaceData(here it is XRenderPixMap ArgbPre surface) and converts the color to pre-multiplied values. 2) When we call Graphics2D.fillRect() internally before we compose the destination(opaque color) and source(translucent color) we prepare source render rectangle for X Render extension. Here again we convert the already converted color values to premultiplied values. ? Solution : There is no need for us to do non-pre to pre color conversion again at XRender level so it should be removed. Also this logic of non-pre to pre color conversion at XRender was only used when source is Solid color and not Texture/Gradient. So I have completely removed this logic itself as it not needed anywhere else. ? Thanks, Jay ? From Sergey.Bylokhov at oracle.com Tue Jan 16 17:12:28 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 16 Jan 2018 09:12:28 -0800 Subject: [OpenJDK 2D-Dev] RFR JDK-8191174: PngReader throws IllegalArgumentException because ScanlineStride calculation logic is not proper In-Reply-To: References: <6639d1ae-fa52-4505-af5f-1bf3e114fbe5@default> <4903dfdb-8c64-4a38-95e2-549f26b3ee41@default> <045c7f01-106f-4f01-a661-a82ab15c1b1c@default> <74518345-8ed6-44da-b384-01802c01368c@default> <5403b056-4c44-afbf-81dd-82a2d76510de@oracle.com> Message-ID: <65b14f6a-238f-6344-c78d-f93dae801b56@oracle.com> Looks fine. Thank you for clarification. On 14/01/2018 23:08, Jayathirth D V wrote: > Hello Sergey, > > Thanks for reviewing the changes. > > The maximum value of inputBands & bitDepth can be 4 & 16. Also in readHeader() we verify the values present in inputBands & bitDepth and if they are not in required bounds we throw IIOException. So (inputBands * bitDepth) will not cause overflow. > > Also I noticed that we need to use Math.multiplyExact() in skipPass() function too where we have same calculation. > So I have updated the code to reflect the same. > > Please review the updated webrev: > http://cr.openjdk.java.net/~jdv/8191174/webrev.03/ > > Thanks, > Jay > > -----Original Message----- > From: Sergey Bylokhov > Sent: Saturday, January 13, 2018 9:00 AM > To: Jayathirth D V; 2d-dev > Subject: Re: [OpenJDK 2D-Dev] RFR JDK-8191174: PngReader throws IllegalArgumentException because ScanlineStride calculation logic is not proper > > Hi, Jay. > Can you please confirm that it is not possible to get overflow in: > "inputBands * bitDepth"? > 1051 int bitsPerRow = Math.multiplyExact((inputBands * bitDepth), passWidth); > > On 08/01/2018 02:04, Jayathirth D V wrote: >> As you have mentioned throwing "Pixel stride times width must be less than or equal to the scanline stride" is not proper in this scenario as image contains proper width as per PNG specification. >> Thanks for pointing to Math.multiplyExact() function and it is very beneficial for solving this issue. While calculating bytesPerRow itself we can use Math.multiplyExact() and throw "int overflow" ArithmeticException and it will be wrapped into IIOException because of changes present in https://bugs.openjdk.java.net/browse/JDK-8190332 . >> >> By doing this we will not have multiple "Caused by" chain and we will be throwing proper exception as per ImageIO specification. >> Please find updated webrev for review: >> http://cr.openjdk.java.net/~jdv/8191174/webrev.02/ >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Sergey Bylokhov >> Sent: Saturday, January 06, 2018 2:45 PM >> To: Prahalad Kumar Narayanan; Jayathirth D V; 2d-dev >> Subject: Re: [OpenJDK 2D-Dev] RFR JDK-8191174: PngReader throws >> IllegalArgumentException because ScanlineStride calculation logic is >> not proper >> >> Probably we can use Math.multiplyExact()? The current exception text wrapped a few times "Pixel stride times width must be less than or equal to the scanline stride" is not strictly correct because it is possible that the image itself has correct data, but we cannot handle it because of overflow. >> >> On 28/12/2017 22:49, Prahalad Kumar Narayanan wrote: >>> Hello Jay >>> >>> Good day to you. >>> >>> The code changes wrap the IllegalArgumentException in IIOException. >>> This approach is better & aligns with how OutOfMemoryError was wrapped to fix JDK-8190332. >>> >>> The only point that I 'm not sure is- whether we could wrap IllegalArgumentException twice before throwing to the user code. >>> >>> javax.imageio.IIOException: Error reading PNG image data >>> at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.readImage >>> at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.read >>> at java.desktop/javax.imageio.ImageIO.read >>> ... >>> Caused by: javax.imageio.IIOException: Caught exception during read: >>> at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.decodePass >>> at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.decodeImage >>> ... >>> Caused by: java.lang.IllegalArgumentException: Pixel stride times width must be less than or equal to the scanline stride >>> at java.desktop/java.awt.image.PixelInterleavedSampleModel. >>> at java.desktop/java.awt.image.Raster.createInterleavedRaster >>> at >>> java.desktop/com.sun.imageio.plugins.png.PNGImageReader.createRaster >>> >>> Since there are multiple levels of same exception, programmer could have trouble getting the cause using getCause() method. >>> However, Invoking printStackTrace() on the outer most exception object gives complete call stack (as listed above). >>> So I think, this should be ok. >>> >>> I would like to know of others' opinion too. >>> >>> Thank you >>> Have a good day >>> >>> Prahalad N. >>> >>> >>> -----Original Message----- >>> From: Jayathirth D V >>> Sent: Thursday, December 28, 2017 3:43 PM >>> To: Prahalad Kumar Narayanan; 2d-dev >>> Subject: RE: [OpenJDK 2D-Dev] RFR JDK-8191174: PngReader throws >>> IllegalArgumentException because ScanlineStride calculation logic is >>> not proper >>> >>> Hi Prahalad, >>> >>> Thanks for your valuable inputs. >>> >>> Even though the fix resolves the issue for the particular test case we have it will not solve the buffer overflow problem as you have mentioned in highest limit case or many other cases where the computed value is very high. >>> >>> Also we cannot change datatype of bytesPerRow/eltsPerRow as they are used in many passed to many other Raster and Stream API's. The best approach to resolve this issue would be to wrap the Exception that we are getting while creating Raster/SampleModel into an IIOException as we have done in https://bugs.openjdk.java.net/browse/JDK-8190332 . By doing this we will abide by specification and also we will have complete stack of why we got the exception so that it can be debugged properly in future. >>> >>> Please find updated webrev for review: >>> http://cr.openjdk.java.net/~jdv/8191174/webrev.01/ >>> >>> Thanks, >>> Jay >>> >>> -----Original Message----- >>> From: Prahalad Kumar Narayanan >>> Sent: Tuesday, December 19, 2017 3:08 PM >>> To: Jayathirth D V; 2d-dev >>> Subject: RE: [OpenJDK 2D-Dev] RFR JDK-8191174: PngReader throws >>> IllegalArgumentException because ScanlineStride calculation logic is >>> not proper >>> >>> >>> Hello Jay >>> >>> Good day to you. >>> >>> I don't think it's possible to fix this issue despite having intermediate " long " variable to hold intermediate bits per pixel. >>> Here is a simple math that considers the worst case scenario with max values: >>> >>> . As per the PNG specification, the maximum permissible width, number of bands, bit-depth are as follows- >>> max_width : (2 ^ 31) - 1 = 2147483647 >>> max_input_bands = 4 >>> max_bit_depth = 16 (2 Bytes) >>> >>> . As per the logic proposed in the fix, the intermediate bits per row would fit into a "long" variable but bytes per pixel would not fit into "int" variable. >>> // Fits into "long" data type >>> max_bits_per_row = max_width * max_input_bands * max_bit_depth >>> = 2147483647 x 4 x 16 >>> = 137438953408 >>> >>> // Does not fit into "int" data type >>> max_bytes_per_row = max_bits_per_row + 7 / 8 >>> = 17179869176 >>> = (0x 3FFFFFFF8 - >>> Goes beyond 4B boundary) >>> >>> // Upon division by 2 for 16-bit images >>> max_elts_per_row = max_bytes_per_row / 2 >>> = 8589934588 >>> = (0x 1FFFFFFFC - Goes >>> beyond 4B boundary) >>> >>> . If we intend to store bytes per row (and eltsPerRow which is scanline stride) in a "long" variable, the same cannot be sent to Raster APIs because the APIs accept "int" type for scanline stride in arguments list. >>> Going by the Raster APIs used in PNGImageReader, a proper fix would require changes to its APIs as well to handle such large scanline stride values. >>> >>> Thank you >>> Have a good day >>> >>> Prahalad N. >>> >>> ----- Original Message ----- >>> From: Jayathirth D V >>> Sent: Thursday, December 14, 2017 1:48 PM >>> To: 2d-dev >>> Subject: [OpenJDK 2D-Dev] RFR JDK-8191174: PngReader throws >>> IllegalArgumentException because ScanlineStride calculation logic is >>> not proper >>> >>> Hello All, >>> >>> Please review the following fix in JDK : >>> >>> Bug : https://bugs.openjdk.java.net/browse/JDK-8191174 >>> Webrev : http://cr.openjdk.java.net/~jdv/8191174/webrev.00/ >>> >>> Issue : When we try to read PNG image with large width we throw undocumented IllegalArgumentException with message "Pixel stride times width must be less than or equal to the scanline stride". >>> >>> Exception in thread "main" java.lang.IllegalArgumentException: Pixel >>> stride times width must be less than or equal to the scanline stride >>> ??????????????? at >>> java.desktop/java.awt.image.PixelInterleavedSampleModel.(PixelI >>> n >>> terleavedSampleModel.java:101) >>> ??????????????? at >>> java.desktop/java.awt.image.Raster.createInterleavedRaster(Raster.jav >>> a >>> :642) >>> ??????????????? at >>> java.desktop/com.sun.imageio.plugins.png.PNGImageReader.createRaster( >>> P >>> NGImageReader.java:974) >>> ??????????????? at >>> java.desktop/com.sun.imageio.plugins.png.PNGImageReader.decodePass(PN >>> G >>> ImageReader.java:1099) >>> ??????????????? at >>> java.desktop/com.sun.imageio.plugins.png.PNGImageReader.decodeImage(P >>> N >>> GImageReader.java:1295) >>> ??????????????? at >>> java.desktop/com.sun.imageio.plugins.png.PNGImageReader.readImage(PNG >>> I >>> mageReader.java:1420) >>> ??????????????? at >>> java.desktop/com.sun.imageio.plugins.png.PNGImageReader.read(PNGImage >>> R >>> eader.java:1699) >>> ??????????????? at >>> java.desktop/javax.imageio.ImageIO.read(ImageIO.java:1468) >>> ??????????????? at >>> java.desktop/javax.imageio.ImageIO.read(ImageIO.java:1363) >>> ??????????????? at >>> PngReaderLargeWidthStrideTest.main(PngReaderLargeWidthStrideTest.java: >>> 50) >>> >>> Root cause : We use large width present in IHDR and calculate elements per row which is passed as scanlinestride for creating the required raster and its corresponding sample model. ?When the call reaches creation of PixelInterleavedSampleModel it checks the condition of (pixelStride * w) > scanlineStride. Since in our case we pass this condition it throws IllegalArgumentException. We have invalid scanlineStride value because when we calculate elements per row/bytes per row value in PNGImageReader the integer variable buffer is overflowed and we maintain invalid value for bytesPerRow. >>> >>> Solution : We can maintain the intermediate bitsPerRow value in long datatype and calculate bytesPerRow using the long value and then typecast it to int bytesPerRow variable. By doing this we will maintain the required scanlineStride/eltsPerRow value properly. After this solution we will throw proper IIOException because of changes present in JDK-8190332 and not the undocumented IllegalArgumentException. >>> >>> Thanks, >>> Jay >>> >> >> >> -- >> Best regards, Sergey. >> > > > -- > Best regards, Sergey. > -- Best regards, Sergey. From linuxhippy at gmail.com Tue Jan 16 19:05:34 2018 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Tue, 16 Jan 2018 20:05:34 +0100 Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8176795: Wrong color drawn when painting translucent colors on volatile images using XRender. In-Reply-To: <2f2b14a1-eecb-4477-bc17-1ae93e392d88@default> References: <294c9548-0095-4b68-bb6b-1c8d0eba2cc1@default> <78bf6d21-bc93-4c79-8f52-ecb690c5381a@default> <85479031-dc5f-4d6f-b496-662b13604cd1@default> <2f2b14a1-eecb-4477-bc17-1ae93e392d88@default> Message-ID: Hi Jay, > 1) When we call Graphics2D.setColor() it uses ArgbPre PixelConverter based on SurfaceData(here it is XRenderPixMap ArgbPre surface) and converts the color to pre-multiplied values. Thanks a lot for identifying the issue and working on it. The fix itself looks fine and low-risk. Thanks again, Clemens From prahalad.kumar.narayanan at oracle.com Wed Jan 17 05:18:33 2018 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Tue, 16 Jan 2018 21:18:33 -0800 (PST) Subject: [OpenJDK 2D-Dev] RFR JDK-8191174: PngReader throws IllegalArgumentException because ScanlineStride calculation logic is not proper In-Reply-To: <65b14f6a-238f-6344-c78d-f93dae801b56@oracle.com> References: <6639d1ae-fa52-4505-af5f-1bf3e114fbe5@default> <4903dfdb-8c64-4a38-95e2-549f26b3ee41@default> <045c7f01-106f-4f01-a661-a82ab15c1b1c@default> <74518345-8ed6-44da-b384-01802c01368c@default> <5403b056-4c44-afbf-81dd-82a2d76510de@oracle.com> <65b14f6a-238f-6344-c78d-f93dae801b56@oracle.com> Message-ID: <91a41763-4e03-4236-97a7-8a90e1060a50@default> Hello Jay This is a minor change on top of webrev.02. Looks good. Thanks Have a good day Prahalad N. -----Original Message----- From: Sergey Bylokhov Sent: Tuesday, January 16, 2018 10:42 PM To: Jayathirth D V; 2d-dev Subject: Re: [OpenJDK 2D-Dev] RFR JDK-8191174: PngReader throws IllegalArgumentException because ScanlineStride calculation logic is not proper Looks fine. Thank you for clarification. On 14/01/2018 23:08, Jayathirth D V wrote: > Hello Sergey, > > Thanks for reviewing the changes. > > The maximum value of inputBands & bitDepth can be 4 & 16. Also in readHeader() we verify the values present in inputBands & bitDepth and if they are not in required bounds we throw IIOException. So (inputBands * bitDepth) will not cause overflow. > > Also I noticed that we need to use Math.multiplyExact() in skipPass() function too where we have same calculation. > So I have updated the code to reflect the same. > > Please review the updated webrev: > http://cr.openjdk.java.net/~jdv/8191174/webrev.03/ > > Thanks, > Jay > > -----Original Message----- > From: Sergey Bylokhov > Sent: Saturday, January 13, 2018 9:00 AM > To: Jayathirth D V; 2d-dev > Subject: Re: [OpenJDK 2D-Dev] RFR JDK-8191174: PngReader throws > IllegalArgumentException because ScanlineStride calculation logic is > not proper > > Hi, Jay. > Can you please confirm that it is not possible to get overflow in: > "inputBands * bitDepth"? > 1051 int bitsPerRow = Math.multiplyExact((inputBands * bitDepth), > passWidth); > > On 08/01/2018 02:04, Jayathirth D V wrote: >> As you have mentioned throwing "Pixel stride times width must be less than or equal to the scanline stride" is not proper in this scenario as image contains proper width as per PNG specification. >> Thanks for pointing to Math.multiplyExact() function and it is very beneficial for solving this issue. While calculating bytesPerRow itself we can use Math.multiplyExact() and throw "int overflow" ArithmeticException and it will be wrapped into IIOException because of changes present in https://bugs.openjdk.java.net/browse/JDK-8190332 . >> >> By doing this we will not have multiple "Caused by" chain and we will be throwing proper exception as per ImageIO specification. >> Please find updated webrev for review: >> http://cr.openjdk.java.net/~jdv/8191174/webrev.02/ >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Sergey Bylokhov >> Sent: Saturday, January 06, 2018 2:45 PM >> To: Prahalad Kumar Narayanan; Jayathirth D V; 2d-dev >> Subject: Re: [OpenJDK 2D-Dev] RFR JDK-8191174: PngReader throws >> IllegalArgumentException because ScanlineStride calculation logic is >> not proper >> >> Probably we can use Math.multiplyExact()? The current exception text wrapped a few times "Pixel stride times width must be less than or equal to the scanline stride" is not strictly correct because it is possible that the image itself has correct data, but we cannot handle it because of overflow. >> >> On 28/12/2017 22:49, Prahalad Kumar Narayanan wrote: >>> Hello Jay >>> >>> Good day to you. >>> >>> The code changes wrap the IllegalArgumentException in IIOException. >>> This approach is better & aligns with how OutOfMemoryError was wrapped to fix JDK-8190332. >>> >>> The only point that I 'm not sure is- whether we could wrap IllegalArgumentException twice before throwing to the user code. >>> >>> javax.imageio.IIOException: Error reading PNG image data >>> at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.readImage >>> at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.read >>> at java.desktop/javax.imageio.ImageIO.read >>> ... >>> Caused by: javax.imageio.IIOException: Caught exception during read: >>> at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.decodePass >>> at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.decodeImage >>> ... >>> Caused by: java.lang.IllegalArgumentException: Pixel stride times width must be less than or equal to the scanline stride >>> at java.desktop/java.awt.image.PixelInterleavedSampleModel. >>> at java.desktop/java.awt.image.Raster.createInterleavedRaster >>> at >>> java.desktop/com.sun.imageio.plugins.png.PNGImageReader.createRaster >>> >>> Since there are multiple levels of same exception, programmer could have trouble getting the cause using getCause() method. >>> However, Invoking printStackTrace() on the outer most exception object gives complete call stack (as listed above). >>> So I think, this should be ok. >>> >>> I would like to know of others' opinion too. >>> >>> Thank you >>> Have a good day >>> >>> Prahalad N. >>> >>> >>> -----Original Message----- >>> From: Jayathirth D V >>> Sent: Thursday, December 28, 2017 3:43 PM >>> To: Prahalad Kumar Narayanan; 2d-dev >>> Subject: RE: [OpenJDK 2D-Dev] RFR JDK-8191174: PngReader throws >>> IllegalArgumentException because ScanlineStride calculation logic is >>> not proper >>> >>> Hi Prahalad, >>> >>> Thanks for your valuable inputs. >>> >>> Even though the fix resolves the issue for the particular test case we have it will not solve the buffer overflow problem as you have mentioned in highest limit case or many other cases where the computed value is very high. >>> >>> Also we cannot change datatype of bytesPerRow/eltsPerRow as they are used in many passed to many other Raster and Stream API's. The best approach to resolve this issue would be to wrap the Exception that we are getting while creating Raster/SampleModel into an IIOException as we have done in https://bugs.openjdk.java.net/browse/JDK-8190332 . By doing this we will abide by specification and also we will have complete stack of why we got the exception so that it can be debugged properly in future. >>> >>> Please find updated webrev for review: >>> http://cr.openjdk.java.net/~jdv/8191174/webrev.01/ >>> >>> Thanks, >>> Jay >>> >>> -----Original Message----- >>> From: Prahalad Kumar Narayanan >>> Sent: Tuesday, December 19, 2017 3:08 PM >>> To: Jayathirth D V; 2d-dev >>> Subject: RE: [OpenJDK 2D-Dev] RFR JDK-8191174: PngReader throws >>> IllegalArgumentException because ScanlineStride calculation logic is >>> not proper >>> >>> >>> Hello Jay >>> >>> Good day to you. >>> >>> I don't think it's possible to fix this issue despite having intermediate " long " variable to hold intermediate bits per pixel. >>> Here is a simple math that considers the worst case scenario with max values: >>> >>> . As per the PNG specification, the maximum permissible width, number of bands, bit-depth are as follows- >>> max_width : (2 ^ 31) - 1 = 2147483647 >>> max_input_bands = 4 >>> max_bit_depth = 16 (2 Bytes) >>> >>> . As per the logic proposed in the fix, the intermediate bits per row would fit into a "long" variable but bytes per pixel would not fit into "int" variable. >>> // Fits into "long" data type >>> max_bits_per_row = max_width * max_input_bands * max_bit_depth >>> = 2147483647 x 4 x 16 >>> = 137438953408 >>> >>> // Does not fit into "int" data type >>> max_bytes_per_row = max_bits_per_row + 7 / 8 >>> = 17179869176 >>> = (0x 3FFFFFFF8 >>> - Goes beyond 4B boundary) >>> >>> // Upon division by 2 for 16-bit images >>> max_elts_per_row = max_bytes_per_row / 2 >>> = 8589934588 >>> = (0x 1FFFFFFFC - >>> Goes beyond 4B boundary) >>> >>> . If we intend to store bytes per row (and eltsPerRow which is scanline stride) in a "long" variable, the same cannot be sent to Raster APIs because the APIs accept "int" type for scanline stride in arguments list. >>> Going by the Raster APIs used in PNGImageReader, a proper fix would require changes to its APIs as well to handle such large scanline stride values. >>> >>> Thank you >>> Have a good day >>> >>> Prahalad N. >>> >>> ----- Original Message ----- >>> From: Jayathirth D V >>> Sent: Thursday, December 14, 2017 1:48 PM >>> To: 2d-dev >>> Subject: [OpenJDK 2D-Dev] RFR JDK-8191174: PngReader throws >>> IllegalArgumentException because ScanlineStride calculation logic is >>> not proper >>> >>> Hello All, >>> >>> Please review the following fix in JDK : >>> >>> Bug : https://bugs.openjdk.java.net/browse/JDK-8191174 >>> Webrev : http://cr.openjdk.java.net/~jdv/8191174/webrev.00/ >>> >>> Issue : When we try to read PNG image with large width we throw undocumented IllegalArgumentException with message "Pixel stride times width must be less than or equal to the scanline stride". >>> >>> Exception in thread "main" java.lang.IllegalArgumentException: Pixel >>> stride times width must be less than or equal to the scanline stride >>> ??????????????? at >>> java.desktop/java.awt.image.PixelInterleavedSampleModel.(Pixel >>> I >>> n >>> terleavedSampleModel.java:101) >>> ??????????????? at >>> java.desktop/java.awt.image.Raster.createInterleavedRaster(Raster.ja >>> v >>> a >>> :642) >>> ??????????????? at >>> java.desktop/com.sun.imageio.plugins.png.PNGImageReader.createRaster >>> ( >>> P >>> NGImageReader.java:974) >>> ??????????????? at >>> java.desktop/com.sun.imageio.plugins.png.PNGImageReader.decodePass(P >>> N >>> G >>> ImageReader.java:1099) >>> ??????????????? at >>> java.desktop/com.sun.imageio.plugins.png.PNGImageReader.decodeImage( >>> P >>> N >>> GImageReader.java:1295) >>> ??????????????? at >>> java.desktop/com.sun.imageio.plugins.png.PNGImageReader.readImage(PN >>> G >>> I >>> mageReader.java:1420) >>> ??????????????? at >>> java.desktop/com.sun.imageio.plugins.png.PNGImageReader.read(PNGImag >>> e >>> R >>> eader.java:1699) >>> ??????????????? at >>> java.desktop/javax.imageio.ImageIO.read(ImageIO.java:1468) >>> ??????????????? at >>> java.desktop/javax.imageio.ImageIO.read(ImageIO.java:1363) >>> ??????????????? at >>> PngReaderLargeWidthStrideTest.main(PngReaderLargeWidthStrideTest.java: >>> 50) >>> >>> Root cause : We use large width present in IHDR and calculate elements per row which is passed as scanlinestride for creating the required raster and its corresponding sample model. ?When the call reaches creation of PixelInterleavedSampleModel it checks the condition of (pixelStride * w) > scanlineStride. Since in our case we pass this condition it throws IllegalArgumentException. We have invalid scanlineStride value because when we calculate elements per row/bytes per row value in PNGImageReader the integer variable buffer is overflowed and we maintain invalid value for bytesPerRow. >>> >>> Solution : We can maintain the intermediate bitsPerRow value in long datatype and calculate bytesPerRow using the long value and then typecast it to int bytesPerRow variable. By doing this we will maintain the required scanlineStride/eltsPerRow value properly. After this solution we will throw proper IIOException because of changes present in JDK-8190332 and not the undocumented IllegalArgumentException. >>> >>> Thanks, >>> Jay >>> >> >> >> -- >> Best regards, Sergey. >> > > > -- > Best regards, Sergey. > -- Best regards, Sergey. From matthias.baesken at sap.com Wed Jan 17 14:45:30 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 17 Jan 2018 14:45:30 +0000 Subject: [OpenJDK 2D-Dev] RFR 8195615 : libsplashscreen linux ppc64le build error after libpng update - was : RE: jdk-hs ppc64le build error, probably related to libpng update Message-ID: <3bc757e506ae40c5aad26a217fc1eb19@sap.com> Hello I created a bug + webrev for the png / libsplashscreen build issue seen on linux ppc64le . The error because of undefined png_init_filter_functions_vsx is : /open_jdk/jdk_2_build/linuxppc64le/support/native/java.desktop/libsplashscreen/pngrutil.o: In function `png_init_filter_functions': /open_jdk/jdk_2/jdk/src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c:4134: undefined reference to png_init_filter_functions_vsx' The issue has been observed on a SLES12 SP1 ppc64le build machine with "gcc version 4.8.5 (SUSE Linux)" . Please review . Bug : https://bugs.openjdk.java.net/browse/JDK-8195615 Webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8195615/ Thanks, Matthias From: Philip Race [mailto:philip.race at oracle.com] Sent: Donnerstag, 28. Dezember 2017 18:09 To: Baesken, Matthias Cc: 2d-dev at openjdk.java.net; Doerr, Martin ; Simonis, Volker Subject: Re: jdk-hs ppc64le build error, probably related to libpng update This all sounds fine to me. Definitely we should report this upstream to see what they say but clearly we aren't bound to wait for an answer from there since this is a build breakage for PPC. If someone upstream comes back with a better answer we can update the fix. I think this png update will get backported to 8u at some point .. the PPC port is supported on 8u, isn't it ? So we'll want to make sure we have the fix before we do the backport. -phil. On 12/28/17, 5:07 AM, Baesken, Matthias wrote: Hi Phil, I think your idea to guard with #ifdef PNG_POWERPC_VSX_API_SUPPORTED Is fine, should I prepare a webrev using this guard ? * Wrapping in that check might be OK (for PNG_POWERPC_VSX_API_SUPPORTED) but you'll want to report this upstream. Yes it is a good idea to report this upstream as well at libpng. Best regards, Matthias From: Phil Race [mailto:philip.race at oracle.com] Sent: Freitag, 22. Dezember 2017 19:08 To: Baesken, Matthias ; 2d-dev at openjdk.java.net Cc: Doerr, Martin ; Simonis, Volker Subject: Re: jdk-hs ppc64le build error, probably related to libpng update I expect that will fix it but I wonder if the problem is that all of this needs to be guarded by checking :- #ifdef PNG_POWERPC_VSX_API_SUPPORTED It looks to me configure would have set that if it had been run on PPC AND you have passed --enable-powerpc-vsx to configure But of course I did not. And someone can set it unsupported anyway. So this seems like a libpng bug. Wrapping in that check might be OK (for PNG_POWERPC_VSX_API_SUPPORTED) but you'll want to report this upstream. I have no intention of pulling in the accelerated code .. even for intel ... this library is used only for splashscreen. -phil. On 12/21/2017 07:13 AM, Baesken, Matthias wrote: >Do you have a version of libpng available that contains the missing function png_init_filter_functions_vsx ? >Or do you have an idea where it should come from (I cannot find it in the main libpng sources). >To fix the build, we could probably disable the part bringing in png_init_filter_functions_vsx in png_init_filter_functions_vsx . Hello, small update - here is a fix that disables the libpng vsx optimizations on ppc64 (and fixes the build issue). Should I prepare a webrev ? Or how to get a ppc64 le / be png_init_filter_functions_vsx implementation ? Best regards, Matthias ----------------------- diff -r d55bee3727de src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.h --- a/src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.h Tue Dec 19 17:31:53 2017 -0500 +++ b/src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.h Wed Dec 20 17:16:01 2017 +0100 @@ -220,12 +220,15 @@ # endif #endif +/* for now avoid the ppc64 vsx optimizations */ #ifndef PNG_POWERPC_VSX_OPT -# if defined(__PPC64__) && defined(__ALTIVEC__) && defined(__VSX__) -# define PNG_POWERPC_VSX_OPT 2 -# else +/* + * # if defined(__PPC64__) && defined(__ALTIVEC__) && defined(__VSX__) + * # define PNG_POWERPC_VSX_OPT 2 + * # else + */ # define PNG_POWERPC_VSX_OPT 0 -# endif +/* # endif */ #endif #ifndef PNG_INTEL_SSE_OPT ----------------------- From: Baesken, Matthias Sent: Mittwoch, 20. Dezember 2017 13:04 To: Phil Race (philip.race at oracle.com) Cc: Doerr, Martin ; Simonis, Volker ; 2d-dev at openjdk.java.net Subject: jdk-hs ppc64le build error, probably related to libpng update Hi Phil, it looks like the recent png lib change 8183960: Upgrade to libpng 1.6.34 http://hg.openjdk.java.net/jdk/hs/rev/791d551bcdb8 +#if PNG_POWERPC_VSX_OPT > 0 +# define PNG_FILTER_OPTIMIZATIONS png_init_filter_functions_vsx +# define PNG_POWERPC_VSX_IMPLEMENTATION 1 +#endif Causes build errors in our linuxppc64le openjdk jdk-hs (fast)dbg build . We get this linker error : pngrutil.c:(.text+0x4824): undefined reference to `png_init_filter_functions_vsx' Do you have a version of libpng available that contains the missing function png_init_filter_functions_vsx ? Or do you have an idea where it should come from (I cannot find it in the main libpng sources). To fix the build, we could probably disable the part bringing in png_init_filter_functions_vsx in png_init_filter_functions_vsx . Thanks, Matthias Error message : * /hs/support/native/java.desktop/libsplashscreen/pngrutil.o: In function `png_read_filter_row': * pngrutil.c:(.text+0x4824): undefined reference to `png_init_filter_functions_vsx' * collect2: error: ld returned 1 exit status * Awt2dLibraries.gmk:928: recipe for target '/hs/support/modules_libs/java.desktop/libsplashscreen.so' failed -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Jan 17 17:04:24 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 17 Jan 2018 09:04:24 -0800 Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8176795: Wrong color drawn when painting translucent colors on volatile images using XRender. In-Reply-To: References: <294c9548-0095-4b68-bb6b-1c8d0eba2cc1@default> <78bf6d21-bc93-4c79-8f52-ecb690c5381a@default> <85479031-dc5f-4d6f-b496-662b13604cd1@default> <2f2b14a1-eecb-4477-bc17-1ae93e392d88@default> Message-ID: +1 from me as well. I had approved the first version of the fix but this one looks fine too. -phil. On 01/16/2018 11:05 AM, Clemens Eisserer wrote: > Hi Jay, > >> 1) When we call Graphics2D.setColor() it uses ArgbPre PixelConverter based on SurfaceData(here it is XRenderPixMap ArgbPre surface) and converts the color to pre-multiplied values. > Thanks a lot for identifying the issue and working on it. > The fix itself looks fine and low-risk. > > Thanks again, Clemens From adam.farley at uk.ibm.com Wed Jan 17 17:30:28 2018 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Wed, 17 Jan 2018 17:30:28 +0000 Subject: [OpenJDK 2D-Dev] [PATCH] Build fails to compile jchuff.c Message-ID: Hi All, Under these circumstances, jchuff.c will not compile: Platform: zLinux (s390x) Release: JDK9 (may affect other JDKs). GCC Version: 4.8.5 Notes: --disable-warnings-as-errors suppresses this error. The error is: /home/adamfarl/hotspot/jdk9/jdk/src/java.desktop/share/native/libjavajpeg/jchuff.c: In function 'jGenOptTbl': /home/adamfarl/hotspot/jdk9/jdk/src/java.desktop/share/native/libjavajpeg/jchuff.c:808:18: error: array subscript is below array bounds [-Werror=array-bounds] while (bits[j] == 0) ^ This is a continuation of a conversation in the build-dev mailing list, if anyone wants to check the history. The short version is that, while you *can* suppress the problem by adding --disable-warnings-as-errors to your configure step, I posit that a builder shouldn't have to. Various solutions were debated. One involves changing Awt2dLibraries.gmk. Basically you change line 494 to this: DISABLED_WARNINGS_gcc := clobbered array-bounds, \ I'm running a build now to check that works, but basically we should end up with a -Wno-array-bounds on the gcc compile command for jchuff.c, thereby ignoring the warning. A smarter variant involves checking for that specific version of the gcc, but that seems wordy to me for this problem. Keeping it simple. :) Thoughts? Best Regards Adam Farley Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Jan 17 21:57:20 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 17 Jan 2018 13:57:20 -0800 Subject: [OpenJDK 2D-Dev] RFR 8195615 : libsplashscreen linux ppc64le build error after libpng update - was : RE: jdk-hs ppc64le build error, probably related to libpng update In-Reply-To: <3bc757e506ae40c5aad26a217fc1eb19@sap.com> References: <3bc757e506ae40c5aad26a217fc1eb19@sap.com> Message-ID: <077043e8-8c24-e5d1-d30b-fae2a1398abe@oracle.com> This looks fine to me. Martin asked (a while ago) if I knew where to report this upstream. I can only suggest what I find via search as being the libpng bug tracker : https://sourceforge.net/p/libpng/bugs/ -phil On 01/17/2018 06:45 AM, Baesken, Matthias wrote: > > Hello I created a bug + webrev for the png / libsplashscreen > build issue seen on linux ppc64le . > > The error because of undefined png_init_filter_functions_vsx is : > > /open_jdk/jdk_2_build/linuxppc64le/support/native/java.desktop/libsplashscreen/pngrutil.o: > In function `png_init_filter_functions': > /open_jdk/jdk_2/jdk/src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c:4134: > undefined reference to png_init_filter_functions_vsx' > > The issue has been observed on a SLES12 SP1 ppc64le build machine with > "gcc version 4.8.5 (SUSE Linux)" . > > Please review . > > Bug : > > https://bugs.openjdk.java.net/browse/JDK-8195615 > > Webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8195615/ > > > Thanks, Matthias > > *From:*Philip Race [mailto:philip.race at oracle.com] > *Sent:* Donnerstag, 28. Dezember 2017 18:09 > *To:* Baesken, Matthias > *Cc:* 2d-dev at openjdk.java.net; Doerr, Martin ; > Simonis, Volker > *Subject:* Re: jdk-hs ppc64le build error, probably related to libpng > update > > This all sounds fine to me. > Definitely we should report this upstream to see what they say but > clearly we aren't bound to wait for an answer from there since this is > a build breakage for PPC. If someone upstream > comes back with a better answer we can update the fix. > > I think this png update will get backported to 8u at some point .. > the PPC port is supported on 8u, isn't it ? So we'll want to make > sure we have the fix before we do the backport. > > -phil. > > On 12/28/17, 5:07 AM, Baesken, Matthias wrote: > > Hi Phil, I think your idea to guard with > > #ifdef PNG_POWERPC_VSX_API_SUPPORTED > > Is fine, should I prepare a webrev using this guard ? > > * Wrapping in that check might be OK (for > PNG_POWERPC_VSX_API_SUPPORTED) but you'll want to report this > upstream. > > Yes it is a good idea to report this upstream as well at libpng. > > Best regards, Matthias > > *From:*Phil Race [mailto:philip.race at oracle.com] > *Sent:* Freitag, 22. Dezember 2017 19:08 > *To:* Baesken, Matthias > ; 2d-dev at openjdk.java.net > > *Cc:* Doerr, Martin > ; Simonis, Volker > > *Subject:* Re: jdk-hs ppc64le build error, probably related to > libpng update > > I expect that will fix it but I wonder if the problem is that all > of this needs > to be guarded by checking :- > > #ifdef PNG_POWERPC_VSX_API_SUPPORTED > > It looks to me configure would have set that if it had been run on > PPC AND > you have passed --enable-powerpc-vsx to configure > > But of course I did not. > > And someone can set it unsupported anyway. > > So this seems like a libpng bug. > > Wrapping in that check might be OK (for > PNG_POWERPC_VSX_API_SUPPORTED) but > you'll want to report this upstream. > > I have no intention of pulling in the accelerated code .. even for > intel ... this > library is used only for splashscreen. > > -phil. > > > > On 12/21/2017 07:13 AM, Baesken, Matthias wrote: > > >Do you have a version of libpng available that contains the > missing function png_init_filter_functions_vsx ? > > >Or do you have an idea where it should come from (I cannot find it in > the main libpng sources). > > >To fix the build, we could probably disable the part bringing in > png_init_filter_functions_vsx in > png_init_filter_functions_vsx . > > Hello, small update - here is a fix that disables the > libpng vsx optimizations on ppc64 (and fixes the build issue). > > Should I prepare a webrev ? Or how to get a ppc64 le / be > png_init_filter_functions_vsx implementation ? > > Best regards, Matthias > > ----------------------- > > diff -r d55bee3727de > src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.h > > --- > a/src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.h > Tue Dec 19 17:31:53 2017 -0500 > > +++ > b/src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.h > Wed Dec 20 17:16:01 2017 +0100 > > @@ -220,12 +220,15 @@ > > # endif > > #endif > > +/* for now avoid the ppc64 vsx optimizations */ > > #ifndef PNG_POWERPC_VSX_OPT > > -# if defined(__PPC64__) && defined(__ALTIVEC__) && > defined(__VSX__) > > -# define PNG_POWERPC_VSX_OPT 2 > > -# else > > +/* > > + * # if defined(__PPC64__) && defined(__ALTIVEC__) && > defined(__VSX__) > > + * # define PNG_POWERPC_VSX_OPT 2 > > + * # else > > + */ > > # define PNG_POWERPC_VSX_OPT 0 > > -# endif > > +/* # endif */ > > #endif > > #ifndef PNG_INTEL_SSE_OPT > > ----------------------- > > *From:*Baesken, Matthias > *Sent:* Mittwoch, 20. Dezember 2017 13:04 > *To:* Phil Race (philip.race at oracle.com > ) > > *Cc:* Doerr, Martin > ; Simonis, Volker > ; > 2d-dev at openjdk.java.net > *Subject:* jdk-hs ppc64le build error, probably related to > libpng update > > Hi Phil, it looks like the recent png lib change > > 8183960: Upgrade to libpng 1.6.34 > > http://hg.openjdk.java.net/jdk/hs/rev/791d551bcdb8 > > +#if PNG_POWERPC_VSX_OPT > 0 > > +# define PNG_FILTER_OPTIMIZATIONS png_init_filter_functions_vsx > > +# define PNG_POWERPC_VSX_IMPLEMENTATION 1 > > +#endif > > Causes build errors in our linuxppc64le openjdk jdk-hs > (fast)dbg build . > > We get this linker error : > > pngrutil.c:(.text+0x4824): undefined reference to > `png_init_filter_functions_vsx' > > Do you have a version of libpng available that contains > the missing function png_init_filter_functions_vsx ? > > Or do you have an idea where it should come from (I cannot > find it in the main libpng sources). > > To fix the build, we could probably disable the part bringing > in png_init_filter_functions_vsx in > png_init_filter_functions_vsx . > > Thanks, Matthias > > Error message : > > * /hs/support/native/java.desktop/libsplashscreen/pngrutil.o: > In function `png_read_filter_row': > * pngrutil.c:(.text+0x4824): undefined reference to > `png_init_filter_functions_vsx' > * collect2: error: ld returned 1 exit status > * Awt2dLibraries.gmk:928: recipe for target > '/hs/support/modules_libs/java.desktop/libsplashscreen.so' > failed > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Thu Jan 18 06:19:22 2018 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Wed, 17 Jan 2018 22:19:22 -0800 (PST) Subject: [OpenJDK 2D-Dev] [11] RFR JDK-8195131: Dead code removal for changes present in JDK-8176795 Message-ID: Hello All, Please review the following fix in JDK11 : Bug : https://bugs.openjdk.java.net/browse/JDK-8195131 Webrev : http://cr.openjdk.java.net/~jdv/8195131/webrev.00/ Issue: After changes present in https://bugs.openjdk.java.net/browse/JDK-8176795 the Non-Premultiplied alpha color to Premultiplied alpha color conversion code present under XRColor.setColorValues() is not reachable. Solution: While fixing https://bugs.openjdk.java.net/browse/JDK-8176795 we decided that we will remove this unreachable/dead code in separate bug so that in future if we need this color conversion code it will be easy to revert. As part of the fix dead code is removed along with minor changes at different files where XRColor.setColorValues() is used. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.baesken at sap.com Thu Jan 18 06:52:35 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 18 Jan 2018 06:52:35 +0000 Subject: [OpenJDK 2D-Dev] RFR 8195615 : libsplashscreen linux ppc64le build error after libpng update - was : RE: jdk-hs ppc64le build error, probably related to libpng update In-Reply-To: <077043e8-8c24-e5d1-d30b-fae2a1398abe@oracle.com> References: <3bc757e506ae40c5aad26a217fc1eb19@sap.com> <077043e8-8c24-e5d1-d30b-fae2a1398abe@oracle.com> Message-ID: Thanks, do I need another review ? ( Here I found the names of the libpng authors + current maintainer : http://www.libpng.org/pub/png/libpng.html ) Best regards, Matthias From: Phil Race [mailto:philip.race at oracle.com] Sent: Mittwoch, 17. Januar 2018 22:57 To: Baesken, Matthias ; 2d-dev at openjdk.java.net Cc: Doerr, Martin ; Simonis, Volker Subject: Re: RFR 8195615 : libsplashscreen linux ppc64le build error after libpng update - was : RE: jdk-hs ppc64le build error, probably related to libpng update This looks fine to me. Martin asked (a while ago) if I knew where to report this upstream. I can only suggest what I find via search as being the libpng bug tracker : https://sourceforge.net/p/libpng/bugs/ -phil On 01/17/2018 06:45 AM, Baesken, Matthias wrote: Hello I created a bug + webrev for the png / libsplashscreen build issue seen on linux ppc64le . The error because of undefined png_init_filter_functions_vsx is : /open_jdk/jdk_2_build/linuxppc64le/support/native/java.desktop/libsplashscreen/pngrutil.o: In function `png_init_filter_functions': /open_jdk/jdk_2/jdk/src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c:4134: undefined reference to png_init_filter_functions_vsx' The issue has been observed on a SLES12 SP1 ppc64le build machine with "gcc version 4.8.5 (SUSE Linux)" . Please review . Bug : https://bugs.openjdk.java.net/browse/JDK-8195615 Webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8195615/ Thanks, Matthias From: Philip Race [mailto:philip.race at oracle.com] Sent: Donnerstag, 28. Dezember 2017 18:09 To: Baesken, Matthias Cc: 2d-dev at openjdk.java.net; Doerr, Martin ; Simonis, Volker Subject: Re: jdk-hs ppc64le build error, probably related to libpng update This all sounds fine to me. Definitely we should report this upstream to see what they say but clearly we aren't bound to wait for an answer from there since this is a build breakage for PPC. If someone upstream comes back with a better answer we can update the fix. I think this png update will get backported to 8u at some point .. the PPC port is supported on 8u, isn't it ? So we'll want to make sure we have the fix before we do the backport. -phil. On 12/28/17, 5:07 AM, Baesken, Matthias wrote: Hi Phil, I think your idea to guard with #ifdef PNG_POWERPC_VSX_API_SUPPORTED Is fine, should I prepare a webrev using this guard ? * Wrapping in that check might be OK (for PNG_POWERPC_VSX_API_SUPPORTED) but you'll want to report this upstream. Yes it is a good idea to report this upstream as well at libpng. Best regards, Matthias From: Phil Race [mailto:philip.race at oracle.com] Sent: Freitag, 22. Dezember 2017 19:08 To: Baesken, Matthias ; 2d-dev at openjdk.java.net Cc: Doerr, Martin ; Simonis, Volker Subject: Re: jdk-hs ppc64le build error, probably related to libpng update I expect that will fix it but I wonder if the problem is that all of this needs to be guarded by checking :- #ifdef PNG_POWERPC_VSX_API_SUPPORTED It looks to me configure would have set that if it had been run on PPC AND you have passed --enable-powerpc-vsx to configure But of course I did not. And someone can set it unsupported anyway. So this seems like a libpng bug. Wrapping in that check might be OK (for PNG_POWERPC_VSX_API_SUPPORTED) but you'll want to report this upstream. I have no intention of pulling in the accelerated code .. even for intel ... this library is used only for splashscreen. -phil. On 12/21/2017 07:13 AM, Baesken, Matthias wrote: >Do you have a version of libpng available that contains the missing function png_init_filter_functions_vsx ? >Or do you have an idea where it should come from (I cannot find it in the main libpng sources). >To fix the build, we could probably disable the part bringing in png_init_filter_functions_vsx in png_init_filter_functions_vsx . Hello, small update - here is a fix that disables the libpng vsx optimizations on ppc64 (and fixes the build issue). Should I prepare a webrev ? Or how to get a ppc64 le / be png_init_filter_functions_vsx implementation ? Best regards, Matthias ----------------------- diff -r d55bee3727de src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.h --- a/src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.h Tue Dec 19 17:31:53 2017 -0500 +++ b/src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.h Wed Dec 20 17:16:01 2017 +0100 @@ -220,12 +220,15 @@ # endif #endif +/* for now avoid the ppc64 vsx optimizations */ #ifndef PNG_POWERPC_VSX_OPT -# if defined(__PPC64__) && defined(__ALTIVEC__) && defined(__VSX__) -# define PNG_POWERPC_VSX_OPT 2 -# else +/* + * # if defined(__PPC64__) && defined(__ALTIVEC__) && defined(__VSX__) + * # define PNG_POWERPC_VSX_OPT 2 + * # else + */ # define PNG_POWERPC_VSX_OPT 0 -# endif +/* # endif */ #endif #ifndef PNG_INTEL_SSE_OPT ----------------------- From: Baesken, Matthias Sent: Mittwoch, 20. Dezember 2017 13:04 To: Phil Race (philip.race at oracle.com) Cc: Doerr, Martin ; Simonis, Volker ; 2d-dev at openjdk.java.net Subject: jdk-hs ppc64le build error, probably related to libpng update Hi Phil, it looks like the recent png lib change 8183960: Upgrade to libpng 1.6.34 http://hg.openjdk.java.net/jdk/hs/rev/791d551bcdb8 +#if PNG_POWERPC_VSX_OPT > 0 +# define PNG_FILTER_OPTIMIZATIONS png_init_filter_functions_vsx +# define PNG_POWERPC_VSX_IMPLEMENTATION 1 +#endif Causes build errors in our linuxppc64le openjdk jdk-hs (fast)dbg build . We get this linker error : pngrutil.c:(.text+0x4824): undefined reference to `png_init_filter_functions_vsx' Do you have a version of libpng available that contains the missing function png_init_filter_functions_vsx ? Or do you have an idea where it should come from (I cannot find it in the main libpng sources). To fix the build, we could probably disable the part bringing in png_init_filter_functions_vsx in png_init_filter_functions_vsx . Thanks, Matthias Error message : * /hs/support/native/java.desktop/libsplashscreen/pngrutil.o: In function `png_read_filter_row': * pngrutil.c:(.text+0x4824): undefined reference to `png_init_filter_functions_vsx' * collect2: error: ld returned 1 exit status * Awt2dLibraries.gmk:928: recipe for target '/hs/support/modules_libs/java.desktop/libsplashscreen.so' failed -------------- next part -------------- An HTML attachment was scrubbed... URL: From prahalad.kumar.narayanan at oracle.com Thu Jan 18 07:14:17 2018 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Wed, 17 Jan 2018 23:14:17 -0800 (PST) Subject: [OpenJDK 2D-Dev] [11] RFR JDK-8195131: Dead code removal for changes present in JDK-8176795 In-Reply-To: References: Message-ID: <7338f346-424e-40c2-a542-3c0dbc774dd6@default> Hello Jay I understand that the last argument to XRColor.setColorValues (int pixel, boolean pre) is set to 'true' at all caller sites. This results in block of code within if (!pre) { ... } not being used at all. 97 if (!pre) { 98 double alphaMult = XRUtils.XFixedToDouble(alpha); 99 this.red = (int) (red * alphaMult); 100 this.green = (int) (green * alphaMult); 101 this.blue = (int) (blue * alphaMult); 102 } Though the snippet is un-used presently, it is not an obsolete code because it helps to create XRColor from non pre-mulitplied alpha color. Hence, I would wish to retain the code from future perspective. The consolation here is that, we are addressing code removal as a separate fix. Thus a revert operation will be easy if need arises in future. So this should be fine. Kindly wait on other reviewers' opinion as well. Thank you Have a good day Prahalad N. ----- Original Message ----- From: Jayathirth D V Sent: Thursday, January 18, 2018 11:49 AM To: 2d-dev Subject: [OpenJDK 2D-Dev] [11] RFR JDK-8195131: Dead code removal for changes present in JDK-8176795 Hello All, Please review the following fix in JDK11 : Bug : https://bugs.openjdk.java.net/browse/JDK-8195131 Webrev : http://cr.openjdk.java.net/~jdv/8195131/webrev.00/ Issue: After changes present in https://bugs.openjdk.java.net/browse/JDK-8176795 the Non-Premultiplied alpha color to Premultiplied alpha color conversion code present under XRColor.setColorValues() is not reachable. Solution: While fixing https://bugs.openjdk.java.net/browse/JDK-8176795 we decided that we will remove this unreachable/dead code in separate bug so that in future if we need this color conversion code it will be easy to revert. As part of the fix dead code is removed along with minor changes at different files where XRColor.setColorValues() is used. Thanks, Jay From philip.race at oracle.com Thu Jan 18 19:14:11 2018 From: philip.race at oracle.com (Phil Race) Date: Thu, 18 Jan 2018 11:14:11 -0800 Subject: [OpenJDK 2D-Dev] [PATCH] Build fails to compile jchuff.c In-Reply-To: References: Message-ID: <2db0bae0-9486-9656-ae83-27b6e28e190b@oracle.com> I agree with what Erik said on build-dev that being specific about the tool chain and the reason are worthwhile and important. We've done that in similar cases. Also these review threads usually should have a subject like RFR: : which means you first need a bug id .. the patch can't be pushed without one anyway. Then the patch should be an in-line diff or a webrev hosted on cr.openjdk.java.net. I think in-line would be OK for this small change. -phil. On 01/17/2018 09:30 AM, Adam Farley8 wrote: > Hi All, > > Under these circumstances, jchuff.c will not compile: > > Platform: zLinux (s390x) > Release: JDK9 (may affect other JDKs). > GCC Version: 4.8.5 > Notes: --disable-warnings-as-errors suppresses this error. > > The error is: > > /home/adamfarl/hotspot/jdk9/jdk/src/java.desktop/share/native/libjavajpeg/jchuff.c: > In function 'jGenOptTbl': > /home/adamfarl/hotspot/jdk9/jdk/src/java.desktop/share/native/libjavajpeg/jchuff.c:808:18: > error: array subscript is below array bounds [-Werror=array-bounds] > while (bits[j] == 0) > ^ > > This is a continuation of a conversation in the build-dev mailing > list, if anyone wants to > check the history. > > The short version is that, while you *can* suppress the problem by adding > --disable-warnings-as-errors to your configure step, I posit that a > builder shouldn't > have to. > > Various solutions were debated. One involves changing Awt2dLibraries.gmk. > > Basically you change line 494 to this: > > DISABLED_WARNINGS_gcc := clobbered array-bounds, \ > > I'm running a build now to check that works, but basically we should > end up with a > -Wno-array-bounds on the gcc compile command for jchuff.c, thereby > ignoring the warning. > > A smarter variant involves checking for that specific version of the > gcc, but that seems > wordy to me for this problem. Keeping it simple. :) > > Thoughts? > > Best Regards > > Adam Farley > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu Jan 18 19:15:09 2018 From: philip.race at oracle.com (Phil Race) Date: Thu, 18 Jan 2018 11:15:09 -0800 Subject: [OpenJDK 2D-Dev] [PATCH] Build fails to compile jchuff.c In-Reply-To: <2db0bae0-9486-9656-ae83-27b6e28e190b@oracle.com> References: <2db0bae0-9486-9656-ae83-27b6e28e190b@oracle.com> Message-ID: Try again with build-dev cc'd .. -phil. On 01/18/2018 11:14 AM, Phil Race wrote: > I agree with what Erik said on build-dev that being specific about the > tool chain > and the reason are worthwhile and important. We've done that in > similar cases. > > Also these review threads usually should have a subject like > RFR: : > > which means you first need a bug id .. the patch can't be pushed > without one anyway. > > Then the patch should be an in-line diff or a webrev hosted on > cr.openjdk.java.net. > > I think in-line would be OK for this small change. > > -phil. > > On 01/17/2018 09:30 AM, Adam Farley8 wrote: >> Hi All, >> >> Under these circumstances, jchuff.c will not compile: >> >> Platform: zLinux (s390x) >> Release: JDK9 (may affect other JDKs). >> GCC Version: 4.8.5 >> Notes: --disable-warnings-as-errors suppresses this error. >> >> The error is: >> >> /home/adamfarl/hotspot/jdk9/jdk/src/java.desktop/share/native/libjavajpeg/jchuff.c: >> In function 'jGenOptTbl': >> /home/adamfarl/hotspot/jdk9/jdk/src/java.desktop/share/native/libjavajpeg/jchuff.c:808:18: >> error: array subscript is below array bounds [-Werror=array-bounds] >> while (bits[j] == 0) >> ^ >> >> This is a continuation of a conversation in the build-dev mailing >> list, if anyone wants to >> check the history. >> >> The short version is that, while you *can* suppress the problem by >> adding >> --disable-warnings-as-errors to your configure step, I posit that a >> builder shouldn't >> have to. >> >> Various solutions were debated. One involves changing >> Awt2dLibraries.gmk. >> >> Basically you change line 494 to this: >> >> DISABLED_WARNINGS_gcc := clobbered array-bounds, \ >> >> I'm running a build now to check that works, but basically we should >> end up with a >> -Wno-array-bounds on the gcc compile command for jchuff.c, thereby >> ignoring the warning. >> >> A smarter variant involves checking for that specific version of the >> gcc, but that seems >> wordy to me for this problem. Keeping it simple. :) >> >> Thoughts? >> >> Best Regards >> >> Adam Farley >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with >> number 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire >> PO6 3AU > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Mon Jan 22 10:50:12 2018 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 22 Jan 2018 02:50:12 -0800 (PST) Subject: [OpenJDK 2D-Dev] [11] RFR JDK-8191023: PngReader throws NegativeArraySizeException when keyword length exceeds chunk size Message-ID: <95b1aabc-1c6f-4c11-be71-e06fe83e2dc9@default> Hello All, Please review the following fix in JDK11 : Bug : https://bugs.openjdk.java.net/browse/JDK-8191023 Webrev : http://cr.openjdk.java.net/~jdv/8191023/webrev.00/ Note : Submitter has raised 3 bugs JDK-8191023 , JDK-8191076 , JDK-8191109 with similar issue but in 3 different PNG chunks. I have closed two bugs and kept first opened JBS bug for this issue. From the closed bug test samples are picked and merged into one test case. Issue: When the issue was reported PNGImageReader was throwing NegativeArraySizeException when chunk length is malformed and it exceeds keyword length. After changes present in https://bugs.openjdk.java.net/browse/JDK-8190332 the NegativeArraySizeException is wrapped inside IIOException. Exception in thread "main" javax.imageio.IIOException: Caught exception during read: at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.read(PNGImageReader.java:1707) at java.desktop/javax.imageio.ImageIO.read(ImageIO.java:1468) at java.desktop/javax.imageio.ImageIO.read(ImageIO.java:1363) at PngReaderTextChunkKeywordSizeTest.main(PngReaderTextChunkKeywordSizeTest.java:19) Caused by: java.lang.NegativeArraySizeException at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.parse_tEXt_chunk(PNGImageReader.java:563) at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.readMetadata(PNGImageReader.java:816) at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.readImage(PNGImageReader.java:1331) at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.read(PNGImageReader.java:1700) Root cause : Since the chunk length present is lesser than keyword length. When we try to parse individual chunks and create byte Array to store remaining data in the chunk. We calculate the byte array size from chunk length and size of alreadt parsed data like keyword (like chunkLength - keyword.length() - 2). This results in negative value and it causes NegativeArraySizeException when we try to create the byte Array. Solution: Add check in parse function of all the individual chunks to check for negative value for the size of the remaining data to be stored. We have PNG stream data from 3 bugs with which we can reproduce this issue for zTXt, tEXt and iCCP chunk but we don't have stream data for iTXt chunk but still I have added similar check in parse_iTXt_chunk() function also. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From prahalad.kumar.narayanan at oracle.com Tue Jan 23 02:53:47 2018 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Mon, 22 Jan 2018 18:53:47 -0800 (PST) Subject: [OpenJDK 2D-Dev] [11] RFR JDK-8191023: PngReader throws NegativeArraySizeException when keyword length exceeds chunk size In-Reply-To: <95b1aabc-1c6f-4c11-be71-e06fe83e2dc9@default> References: <95b1aabc-1c6f-4c11-be71-e06fe83e2dc9@default> Message-ID: <3927fa90-b906-4ad3-b780-20a70d03778e@default> Hello Jay I looked into the bug and the fix. The root cause of the problem is mal-formed "chunk length" field. Thus the available chunk data to decode could either be larger (or) lesser than the value of "chunk length". The bug seems to target one specific case- where available data is larger than value of "Chunk length". Moreover bug targets few chunks alone. When a "chunk length" is mal-formed, exceptions could be triggered while reading any data (not just the case indicated by the bug). There are 4 critical chunks and as many as 12 ancillary chunks that may appear in a PNG stream. Adding checks for every individual case would flood the PNG image reader with if (...) checks. Can you think of any better solution to detect mal-formed "chunk length" and chunk data ? How about using the chunk's CRC field ? You could generate CRC with data read from the stream and compare it against the CRC stored for the chunk to validate. Thank you Have a good day Prahalad N. ----- Original Message ----- From: Jayathirth D V Sent: Monday, January 22, 2018 4:20 PM To: 2d-dev Subject: [OpenJDK 2D-Dev] [11] RFR JDK-8191023: PngReader throws NegativeArraySizeException when keyword length exceeds chunk size Hello All, Please review the following fix in JDK11 : Bug : https://bugs.openjdk.java.net/browse/JDK-8191023 Webrev : http://cr.openjdk.java.net/~jdv/8191023/webrev.00/ Note : Submitter has raised 3 bugs JDK-8191023 , JDK-8191076 , JDK-8191109 with similar issue but in 3 different PNG chunks. I have closed two bugs and kept first opened JBS bug for this issue. From the closed bug test samples are picked and merged into one test case. Issue: When the issue was reported PNGImageReader was throwing NegativeArraySizeException when chunk length is malformed and it exceeds keyword length. After changes present in https://bugs.openjdk.java.net/browse/JDK-8190332 the NegativeArraySizeException is wrapped inside IIOException. Exception in thread "main" javax.imageio.IIOException: Caught exception during read: at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.read(PNGImageReader.java:1707) at java.desktop/javax.imageio.ImageIO.read(ImageIO.java:1468) at java.desktop/javax.imageio.ImageIO.read(ImageIO.java:1363) at PngReaderTextChunkKeywordSizeTest.main(PngReaderTextChunkKeywordSizeTest.java:19) Caused by: java.lang.NegativeArraySizeException at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.parse_tEXt_chunk(PNGImageReader.java:563) at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.readMetadata(PNGImageReader.java:816) at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.readImage(PNGImageReader.java:1331) at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.read(PNGImageReader.java:1700) Root cause : Since the chunk length present is lesser than keyword length. When we try to parse individual chunks and create byte Array to store remaining data in the chunk. We calculate the byte array size from chunk length and size of alreadt parsed data like keyword (like chunkLength - keyword.length() - 2). This results in negative value and it causes NegativeArraySizeException when we try to create the byte Array. Solution: Add check in parse function of all the individual chunks to check for negative value for the size of the remaining data to be stored. We have PNG stream data from 3 bugs with which we can reproduce this issue for zTXt, tEXt and iCCP chunk but we don't have stream data for iTXt chunk but still I have added similar check in parse_iTXt_chunk() function also. Thanks, Jay From jayathirth.d.v at oracle.com Tue Jan 23 06:48:17 2018 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 22 Jan 2018 22:48:17 -0800 (PST) Subject: [OpenJDK 2D-Dev] [11] RFR JDK-8191023: PngReader throws NegativeArraySizeException when keyword length exceeds chunk size In-Reply-To: <3927fa90-b906-4ad3-b780-20a70d03778e@default> References: <95b1aabc-1c6f-4c11-be71-e06fe83e2dc9@default> <3927fa90-b906-4ad3-b780-20a70d03778e@default> Message-ID: <638b159c-458f-4f87-b3df-fc748ca9dd21@default> Hi Prahalad, Thanks for providing your inputs. Regarding the CRC check, as of now in PNGImageReader.readMetadata() we store CRC value for each chunk based on read chunk length before parsing them and after parsing a given chunk we verify the CRC value at the end of the chunk with already stored value. If they differ we throw IIOException. Please let me know if you are suggesting some other logic related to CRC check. Also we check negative chunk length value and throw IIOException before we start parsing a chunk. Main issue in this bug is while we are parsing a chunk, we use the available chunk length to determine the remaining length that should be parsed. So only when we parse these individual chunks we get to know the data present in them like keyword.length(). In our test sample scenario we hit a condition while we are parsing where the present chunk length is less than keyword.length() and when we try to create byte array using this value we hit NegativeArraySizeException. We will not reach this problem scenario until we parse these individual chunks. Regarding the problem in other PNG chunks, I went through all the chunk parsing functions and wherever I saw that we are using available chunk length and subtracting some value from it and it might cause NegativeArraySizeException I have added additional checks(in sPLT & tRNS). Please find updated webrev for review : http://cr.openjdk.java.net/~jdv/8191023/webrev.01/ Thanks, Jay -----Original Message----- From: Prahalad Kumar Narayanan Sent: Tuesday, January 23, 2018 8:24 AM To: Jayathirth D V; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-8191023: PngReader throws NegativeArraySizeException when keyword length exceeds chunk size Hello Jay I looked into the bug and the fix. The root cause of the problem is mal-formed "chunk length" field. Thus the available chunk data to decode could either be larger (or) lesser than the value of "chunk length". The bug seems to target one specific case- where available data is larger than value of "Chunk length". Moreover bug targets few chunks alone. When a "chunk length" is mal-formed, exceptions could be triggered while reading any data (not just the case indicated by the bug). There are 4 critical chunks and as many as 12 ancillary chunks that may appear in a PNG stream. Adding checks for every individual case would flood the PNG image reader with if (...) checks. Can you think of any better solution to detect mal-formed "chunk length" and chunk data ? How about using the chunk's CRC field ? You could generate CRC with data read from the stream and compare it against the CRC stored for the chunk to validate. Thank you Have a good day Prahalad N. ----- Original Message ----- From: Jayathirth D V Sent: Monday, January 22, 2018 4:20 PM To: 2d-dev Subject: [OpenJDK 2D-Dev] [11] RFR JDK-8191023: PngReader throws NegativeArraySizeException when keyword length exceeds chunk size Hello All, Please review the following fix in JDK11 : Bug : https://bugs.openjdk.java.net/browse/JDK-8191023 Webrev : http://cr.openjdk.java.net/~jdv/8191023/webrev.00/ Note : Submitter has raised 3 bugs JDK-8191023 , JDK-8191076 , JDK-8191109 with similar issue but in 3 different PNG chunks. I have closed two bugs and kept first opened JBS bug for this issue. From the closed bug test samples are picked and merged into one test case. Issue: When the issue was reported PNGImageReader was throwing NegativeArraySizeException when chunk length is malformed and it exceeds keyword length. After changes present in https://bugs.openjdk.java.net/browse/JDK-8190332 the NegativeArraySizeException is wrapped inside IIOException. Exception in thread "main" javax.imageio.IIOException: Caught exception during read: at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.read(PNGImageReader.java:1707) at java.desktop/javax.imageio.ImageIO.read(ImageIO.java:1468) at java.desktop/javax.imageio.ImageIO.read(ImageIO.java:1363) at PngReaderTextChunkKeywordSizeTest.main(PngReaderTextChunkKeywordSizeTest.java:19) Caused by: java.lang.NegativeArraySizeException at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.parse_tEXt_chunk(PNGImageReader.java:563) at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.readMetadata(PNGImageReader.java:816) at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.readImage(PNGImageReader.java:1331) at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.read(PNGImageReader.java:1700) Root cause : Since the chunk length present is lesser than keyword length. When we try to parse individual chunks and create byte Array to store remaining data in the chunk. We calculate the byte array size from chunk length and size of alreadt parsed data like keyword (like chunkLength - keyword.length() - 2). This results in negative value and it causes NegativeArraySizeException when we try to create the byte Array. Solution: Add check in parse function of all the individual chunks to check for negative value for the size of the remaining data to be stored. We have PNG stream data from 3 bugs with which we can reproduce this issue for zTXt, tEXt and iCCP chunk but we don't have stream data for iTXt chunk but still I have added similar check in parse_iTXt_chunk() function also. Thanks, Jay From prahalad.kumar.narayanan at oracle.com Tue Jan 23 07:17:41 2018 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Mon, 22 Jan 2018 23:17:41 -0800 (PST) Subject: [OpenJDK 2D-Dev] [11] RFR JDK-8191023: PngReader throws NegativeArraySizeException when keyword length exceeds chunk size In-Reply-To: <638b159c-458f-4f87-b3df-fc748ca9dd21@default> References: <95b1aabc-1c6f-4c11-be71-e06fe83e2dc9@default> <3927fa90-b906-4ad3-b780-20a70d03778e@default> <638b159c-458f-4f87-b3df-fc748ca9dd21@default> Message-ID: <40f28961-ad7b-4bfe-b8aa-a8545e14b283@default> Hello Jay The existing verification of CRC value with already stored value is only to ensure we have processed right amount of data. This is done at the end and is explained in the comments at Line 853. It does not validate whether a chunk (length/ data) is valid upfront. Here is the code: 728 try { 729 stream.mark(); 730 stream.seek(stream.getStreamPosition() + chunkLength); 731 chunkCRC = stream.readInt(); 732 stream.reset(); 733 } catch (IOException e) { 734 throw new IIOException("Invalid chunk length " + chunkLength); 735 } 736 737 switch (chunkType) { ... 853 // double check whether all chunk data were consumed 854 if (chunkCRC != stream.readInt()) { 855 throw new IIOException("Failed to read a chunk of type " + 856 chunkType); 857 } My suggestion was to - . 'Generate' CRC from Chunk data and compare it with the retrieved value at Line 731 'before' proceeding to process any of the chunks. . In mal-formed chunks (corrupted chunk length /or chunk data), the CRC check will fail thus giving an effective way to identify a valid chunk. . Many of the if (...) conditions that 've been added to parse_ methods can be avoided with CRC check done upfront. Hope this helps. Thank you Have a good day Prahalad N. -----Original Message----- From: Jayathirth D V Sent: Tuesday, January 23, 2018 12:18 PM To: Prahalad Kumar Narayanan; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-8191023: PngReader throws NegativeArraySizeException when keyword length exceeds chunk size Hi Prahalad, Thanks for providing your inputs. Regarding the CRC check, as of now in PNGImageReader.readMetadata() we store CRC value for each chunk based on read chunk length before parsing them and after parsing a given chunk we verify the CRC value at the end of the chunk with already stored value. If they differ we throw IIOException. Please let me know if you are suggesting some other logic related to CRC check. Also we check negative chunk length value and throw IIOException before we start parsing a chunk. Main issue in this bug is while we are parsing a chunk, we use the available chunk length to determine the remaining length that should be parsed. So only when we parse these individual chunks we get to know the data present in them like keyword.length(). In our test sample scenario we hit a condition while we are parsing where the present chunk length is less than keyword.length() and when we try to create byte array using this value we hit NegativeArraySizeException. We will not reach this problem scenario until we parse these individual chunks. Regarding the problem in other PNG chunks, I went through all the chunk parsing functions and wherever I saw that we are using available chunk length and subtracting some value from it and it might cause NegativeArraySizeException I have added additional checks(in sPLT & tRNS). Please find updated webrev for review : http://cr.openjdk.java.net/~jdv/8191023/webrev.01/ Thanks, Jay -----Original Message----- From: Prahalad Kumar Narayanan Sent: Tuesday, January 23, 2018 8:24 AM To: Jayathirth D V; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-8191023: PngReader throws NegativeArraySizeException when keyword length exceeds chunk size Hello Jay I looked into the bug and the fix. The root cause of the problem is mal-formed "chunk length" field. Thus the available chunk data to decode could either be larger (or) lesser than the value of "chunk length". The bug seems to target one specific case- where available data is larger than value of "Chunk length". Moreover bug targets few chunks alone. When a "chunk length" is mal-formed, exceptions could be triggered while reading any data (not just the case indicated by the bug). There are 4 critical chunks and as many as 12 ancillary chunks that may appear in a PNG stream. Adding checks for every individual case would flood the PNG image reader with if (...) checks. Can you think of any better solution to detect mal-formed "chunk length" and chunk data ? How about using the chunk's CRC field ? You could generate CRC with data read from the stream and compare it against the CRC stored for the chunk to validate. Thank you Have a good day Prahalad N. ----- Original Message ----- From: Jayathirth D V Sent: Monday, January 22, 2018 4:20 PM To: 2d-dev Subject: [OpenJDK 2D-Dev] [11] RFR JDK-8191023: PngReader throws NegativeArraySizeException when keyword length exceeds chunk size Hello All, Please review the following fix in JDK11 : Bug : https://bugs.openjdk.java.net/browse/JDK-8191023 Webrev : http://cr.openjdk.java.net/~jdv/8191023/webrev.00/ Note : Submitter has raised 3 bugs JDK-8191023 , JDK-8191076 , JDK-8191109 with similar issue but in 3 different PNG chunks. I have closed two bugs and kept first opened JBS bug for this issue. From the closed bug test samples are picked and merged into one test case. Issue: When the issue was reported PNGImageReader was throwing NegativeArraySizeException when chunk length is malformed and it exceeds keyword length. After changes present in https://bugs.openjdk.java.net/browse/JDK-8190332 the NegativeArraySizeException is wrapped inside IIOException. Exception in thread "main" javax.imageio.IIOException: Caught exception during read: at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.read(PNGImageReader.java:1707) at java.desktop/javax.imageio.ImageIO.read(ImageIO.java:1468) at java.desktop/javax.imageio.ImageIO.read(ImageIO.java:1363) at PngReaderTextChunkKeywordSizeTest.main(PngReaderTextChunkKeywordSizeTest.java:19) Caused by: java.lang.NegativeArraySizeException at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.parse_tEXt_chunk(PNGImageReader.java:563) at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.readMetadata(PNGImageReader.java:816) at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.readImage(PNGImageReader.java:1331) at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.read(PNGImageReader.java:1700) Root cause : Since the chunk length present is lesser than keyword length. When we try to parse individual chunks and create byte Array to store remaining data in the chunk. We calculate the byte array size from chunk length and size of alreadt parsed data like keyword (like chunkLength - keyword.length() - 2). This results in negative value and it causes NegativeArraySizeException when we try to create the byte Array. Solution: Add check in parse function of all the individual chunks to check for negative value for the size of the remaining data to be stored. We have PNG stream data from 3 bugs with which we can reproduce this issue for zTXt, tEXt and iCCP chunk but we don't have stream data for iTXt chunk but still I have added similar check in parse_iTXt_chunk() function also. Thanks, Jay From adam.farley at uk.ibm.com Tue Jan 23 13:44:40 2018 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Tue, 23 Jan 2018 13:44:40 +0000 Subject: [OpenJDK 2D-Dev] RFR: Bug Pending: Build fails to compile jchuff.c In-Reply-To: References: <2db0bae0-9486-9656-ae83-27b6e28e190b@oracle.com> Message-ID: Hi All, All: I think I responded to everyone below. Please could a committer or author raise a bug and, if people are happy with this change, line it up for contribution to JDKs 8-11 (assuming 4.8.5 is still the recommended gcc for JDK10 and 11 on SUSE sles)? Erik: One toolchain-specific change, as requested. This was tested on JDK9, so please apply an offset of -1 to the line numbers before applying to JDK10. ----------------------- Start of Diff ----------------------- diff --git a/make/lib/Awt2dLibraries.gmk b/make/lib/Awt2dLibraries.gmk --- a/make/lib/Awt2dLibraries.gmk +++ b/make/lib/Awt2dLibraries.gmk @@ -482,6 +482,14 @@ BUILD_LIBJAVAJPEG_HEADERS := $(addprefix -I, $(LIBJAVAJPEG_SRC)) endif +LIBJAVAJPEG_DISABLED_WARNINGS_gcc := clobbered +ifeq ($(CC_VERSION_NUMBER), 4.8.5) + #Turn off array-bounds warnings for libjava compilation because jchuff.c + #fails to compile on gcc 4.8.5 with a warning that an array is potentially + #out of bounds. This kills a warnings=errors build. + LIBJAVAJPEG_DISABLED_WARNINGS_gcc := clobbered array-bounds +endif + $(eval $(call SetupNativeCompilation,BUILD_LIBJAVAJPEG, \ LIBRARY := javajpeg, \ OUTPUT_DIR := $(INSTALL_LIBRARIES_HERE), \ @@ -491,7 +499,7 @@ CFLAGS := $(CFLAGS_JDKLIB) $(BUILD_LIBJAVAJPEG_HEADERS) \ $(LIBJAVA_HEADER_FLAGS) \ -I$(SUPPORT_OUTPUTDIR)/headers/java.desktop, \ - DISABLED_WARNINGS_gcc := clobbered, \ + DISABLED_WARNINGS_gcc := $(LIBJAVAJPEG_DISABLED_WARNINGS_gcc), \ MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libjpeg/mapfile-vers, \ LDFLAGS := $(LDFLAGS_JDKLIB) \ $(call SET_SHARED_LIBRARY_ORIGIN), \ ----------------------- End of Diff ----------------------- Phil: I've changed the title as asked and supplied the diff above. However, I can't upload files to cr.openjdk.java.net, nor can I create bugs myself. I understand that authors and committers can, but I don't have those privileges yet. Be nice if I did. :) John: I read your email, and I understand your position. I disagree with it, but I understand it. 4.8.5 is an old version of gcc, but right now it is the listed gcc version for SUSE sles on intel, ppc, ppcle, and zLinux. Even if this is not the case for JDK 10 or 11, we should ensure this fix is fully propagated to ensure consistent behaviour. That is my position. David: Thanks for the URL. I agree with your position on 4.8.5 gcc needing to compile OpenJDK without errors or special options. :) Best Regards Adam Farley From: Phil Race To: Adam Farley8 , 2d-dev at openjdk.java.net Cc: build-dev Date: 18/01/2018 19:16 Subject: Re: [OpenJDK 2D-Dev] [PATCH] Build fails to compile jchuff.c Try again with build-dev cc'd .. -phil. On 01/18/2018 11:14 AM, Phil Race wrote: I agree with what Erik said on build-dev that being specific about the tool chain and the reason are worthwhile and important. We've done that in similar cases. Also these review threads usually should have a subject like RFR: : which means you first need a bug id .. the patch can't be pushed without one anyway. Then the patch should be an in-line diff or a webrev hosted on cr.openjdk.java.net. I think in-line would be OK for this small change. -phil. On 01/17/2018 09:30 AM, Adam Farley8 wrote: Hi All, Under these circumstances, jchuff.c will not compile: Platform: zLinux (s390x) Release: JDK9 (may affect other JDKs). GCC Version: 4.8.5 Notes: --disable-warnings-as-errors suppresses this error. The error is: /home/adamfarl/hotspot/jdk9/jdk/src/java.desktop/share/native/libjavajpeg/jchuff.c: In function 'jGenOptTbl': /home/adamfarl/hotspot/jdk9/jdk/src/java.desktop/share/native/libjavajpeg/jchuff.c:808:18: error: array subscript is below array bounds [-Werror=array-bounds] while (bits[j] == 0) ^ This is a continuation of a conversation in the build-dev mailing list, if anyone wants to check the history. The short version is that, while you *can* suppress the problem by adding --disable-warnings-as-errors to your configure step, I posit that a builder shouldn't have to. Various solutions were debated. One involves changing Awt2dLibraries.gmk. Basically you change line 494 to this: DISABLED_WARNINGS_gcc := clobbered array-bounds, \ I'm running a build now to check that works, but basically we should end up with a -Wno-array-bounds on the gcc compile command for jchuff.c, thereby ignoring the warning. A smarter variant involves checking for that specific version of the gcc, but that seems wordy to me for this problem. Keeping it simple. :) Thoughts? Best Regards Adam Farley Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.farley at uk.ibm.com Tue Jan 23 14:13:31 2018 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Tue, 23 Jan 2018 14:13:31 +0000 Subject: [OpenJDK 2D-Dev] RFR: Bug Pending: Build fails to compile jchuff.c In-Reply-To: <77b60641-b0eb-ce7d-fe39-c53808e5e221@physik.fu-berlin.de> References: <2db0bae0-9486-9656-ae83-27b6e28e190b@oracle.com> <77b60641-b0eb-ce7d-fe39-c53808e5e221@physik.fu-berlin.de> Message-ID: > On 01/23/2018 02:44 PM, Adam Farley8 wrote: >> John: I read your email, and I understand your position. I disagree with it, >> but I understand it. 4.8.5 is an old version of gcc, but right now it is the >> listed gcc version for SUSE sles on intel, ppc, ppcle, and zLinux. Even if >> this is not the case for JDK 10 or 11, we should ensure this fix is fully >> propagated to ensure consistent behaviour. >> >> That is my position. > I happen to work at SUSE. And while you're right that SLE-12:GA is on gcc > 4.8.x, SLE-12 doesn't have openjdk-9 or openjdk-10 or even -11 in its > update repositories (looking at the internal SUSE build system at the moment). > > openjdk-9 is part of SLE-15:GA which itself ships gcc-7. > > So, what exactly is the usecase for OpenJDK-9, 10 and 11? > > Adrian Hi Adrian, The URL supplied by David (Holmes) lists 4.8.5 as the gcc version for building JDK9 on SLES 11.3/12.1. Whether it's in a repository or not, I read that as "this is the gcc version you should be building JDK9 on". https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms I asked for this change to be put in 10 and 11 because I don't know the minimum/recommended gcc version for jdk10 and 11. I'm assuming it's the same as 9 until told otherwise. Best Regards Adam Farley Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.farley at uk.ibm.com Tue Jan 23 16:25:40 2018 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Tue, 23 Jan 2018 16:25:40 +0000 Subject: [OpenJDK 2D-Dev] RFR: Bug Pending: Build fails to compile jchuff.c In-Reply-To: <150d9e88-4d2f-ac07-bacb-bb61eca68f75@physik.fu-berlin.de> References: <2db0bae0-9486-9656-ae83-27b6e28e190b@oracle.com> <77b60641-b0eb-ce7d-fe39-c53808e5e221@physik.fu-berlin.de> <150d9e88-4d2f-ac07-bacb-bb61eca68f75@physik.fu-berlin.de> Message-ID: > On 01/23/2018 03:13 PM, Adam Farley8 wrote: >> The URL supplied by David (Holmes) lists 4.8.5 as the gcc version for >> building JDK9 on SLES 11.3/12.1. Whether it's in a repository or not, >> I read that as "this is the gcc version you should be building JDK9 on". >> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.openjdk.java.net_display_Build_Supported-2BBuild-2BPlatforms&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf-CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=63AR5zmRQCx5v-MXloqnarJvGvjLXVVnJsui6XMOMoE&s=bDVDenH2BOpYeVaU504vQiL0lqdBlELIy_wWpX44Juw&e= >> >> I asked for this change to be put in 10 and 11 because I don't know the >> minimum/recommended gcc version for jdk10 and 11. I'm assuming it's >> the same as 9 until told otherwise. > > Building OpenJDK-10 or OpenJDK-11 requires OpenJDK-9, so you won't be able > to build them in a fresh SLE-12:SP3 installation anyway. I'm working on the assumption that people will grab binaries from AdoptOpenJDK. > > SLE-11:* doesn't even have OpenJDK-8 and is also going to be out of support > next year anyway. Does this mean the gcc version will change? If you have hard information on this, I'd appreciate the URL. > > I don't necessarily disagree bringing your changes into JDK-8 or JDK-9, > but I don't think they make sense to introduce them to JDK-10 and JDK-11. > > Adrian If the minimum gcc version for 10 or 11 is above 4.8.5 across all platforms, then I agree, but I don't have that information, so I figured I'd ask to cover all of the JDK versions, to be safe. Even if the gcc version does change, adding 4.8.5-specific code shouldn't break anything. What do you think? Best Regards Adam Farley Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.doerr at sap.com Thu Jan 18 09:28:16 2018 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 18 Jan 2018 09:28:16 +0000 Subject: [OpenJDK 2D-Dev] RFR 8195615 : libsplashscreen linux ppc64le build error after libpng update - was : RE: jdk-hs ppc64le build error, probably related to libpng update In-Reply-To: References: <3bc757e506ae40c5aad26a217fc1eb19@sap.com> <077043e8-8c24-e5d1-d30b-fae2a1398abe@oracle.com> Message-ID: <08465e0a6f6f4c45a2706194ae7987b6@sap.com> Hi Matthias, thanks for fixing. Looks good. Reviewed and pushed to jdk10. Best regards, Martin From: Baesken, Matthias Sent: Donnerstag, 18. Januar 2018 07:53 To: Phil Race ; 2d-dev at openjdk.java.net Cc: Doerr, Martin ; Simonis, Volker ; Lindenmaier, Goetz Subject: RE: RFR 8195615 : libsplashscreen linux ppc64le build error after libpng update - was : RE: jdk-hs ppc64le build error, probably related to libpng update Thanks, do I need another review ? ( Here I found the names of the libpng authors + current maintainer : http://www.libpng.org/pub/png/libpng.html ) Best regards, Matthias From: Phil Race [mailto:philip.race at oracle.com] Sent: Mittwoch, 17. Januar 2018 22:57 To: Baesken, Matthias >; 2d-dev at openjdk.java.net Cc: Doerr, Martin >; Simonis, Volker > Subject: Re: RFR 8195615 : libsplashscreen linux ppc64le build error after libpng update - was : RE: jdk-hs ppc64le build error, probably related to libpng update This looks fine to me. Martin asked (a while ago) if I knew where to report this upstream. I can only suggest what I find via search as being the libpng bug tracker : https://sourceforge.net/p/libpng/bugs/ -phil On 01/17/2018 06:45 AM, Baesken, Matthias wrote: Hello I created a bug + webrev for the png / libsplashscreen build issue seen on linux ppc64le . The error because of undefined png_init_filter_functions_vsx is : /open_jdk/jdk_2_build/linuxppc64le/support/native/java.desktop/libsplashscreen/pngrutil.o: In function `png_init_filter_functions': /open_jdk/jdk_2/jdk/src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c:4134: undefined reference to png_init_filter_functions_vsx' The issue has been observed on a SLES12 SP1 ppc64le build machine with "gcc version 4.8.5 (SUSE Linux)" . Please review . Bug : https://bugs.openjdk.java.net/browse/JDK-8195615 Webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8195615/ Thanks, Matthias From: Philip Race [mailto:philip.race at oracle.com] Sent: Donnerstag, 28. Dezember 2017 18:09 To: Baesken, Matthias Cc: 2d-dev at openjdk.java.net; Doerr, Martin ; Simonis, Volker Subject: Re: jdk-hs ppc64le build error, probably related to libpng update This all sounds fine to me. Definitely we should report this upstream to see what they say but clearly we aren't bound to wait for an answer from there since this is a build breakage for PPC. If someone upstream comes back with a better answer we can update the fix. I think this png update will get backported to 8u at some point .. the PPC port is supported on 8u, isn't it ? So we'll want to make sure we have the fix before we do the backport. -phil. On 12/28/17, 5:07 AM, Baesken, Matthias wrote: Hi Phil, I think your idea to guard with #ifdef PNG_POWERPC_VSX_API_SUPPORTED Is fine, should I prepare a webrev using this guard ? * Wrapping in that check might be OK (for PNG_POWERPC_VSX_API_SUPPORTED) but you'll want to report this upstream. Yes it is a good idea to report this upstream as well at libpng. Best regards, Matthias From: Phil Race [mailto:philip.race at oracle.com] Sent: Freitag, 22. Dezember 2017 19:08 To: Baesken, Matthias ; 2d-dev at openjdk.java.net Cc: Doerr, Martin ; Simonis, Volker Subject: Re: jdk-hs ppc64le build error, probably related to libpng update I expect that will fix it but I wonder if the problem is that all of this needs to be guarded by checking :- #ifdef PNG_POWERPC_VSX_API_SUPPORTED It looks to me configure would have set that if it had been run on PPC AND you have passed --enable-powerpc-vsx to configure But of course I did not. And someone can set it unsupported anyway. So this seems like a libpng bug. Wrapping in that check might be OK (for PNG_POWERPC_VSX_API_SUPPORTED) but you'll want to report this upstream. I have no intention of pulling in the accelerated code .. even for intel ... this library is used only for splashscreen. -phil. On 12/21/2017 07:13 AM, Baesken, Matthias wrote: >Do you have a version of libpng available that contains the missing function png_init_filter_functions_vsx ? >Or do you have an idea where it should come from (I cannot find it in the main libpng sources). >To fix the build, we could probably disable the part bringing in png_init_filter_functions_vsx in png_init_filter_functions_vsx . Hello, small update - here is a fix that disables the libpng vsx optimizations on ppc64 (and fixes the build issue). Should I prepare a webrev ? Or how to get a ppc64 le / be png_init_filter_functions_vsx implementation ? Best regards, Matthias ----------------------- diff -r d55bee3727de src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.h --- a/src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.h Tue Dec 19 17:31:53 2017 -0500 +++ b/src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.h Wed Dec 20 17:16:01 2017 +0100 @@ -220,12 +220,15 @@ # endif #endif +/* for now avoid the ppc64 vsx optimizations */ #ifndef PNG_POWERPC_VSX_OPT -# if defined(__PPC64__) && defined(__ALTIVEC__) && defined(__VSX__) -# define PNG_POWERPC_VSX_OPT 2 -# else +/* + * # if defined(__PPC64__) && defined(__ALTIVEC__) && defined(__VSX__) + * # define PNG_POWERPC_VSX_OPT 2 + * # else + */ # define PNG_POWERPC_VSX_OPT 0 -# endif +/* # endif */ #endif #ifndef PNG_INTEL_SSE_OPT ----------------------- From: Baesken, Matthias Sent: Mittwoch, 20. Dezember 2017 13:04 To: Phil Race (philip.race at oracle.com) Cc: Doerr, Martin ; Simonis, Volker ; 2d-dev at openjdk.java.net Subject: jdk-hs ppc64le build error, probably related to libpng update Hi Phil, it looks like the recent png lib change 8183960: Upgrade to libpng 1.6.34 http://hg.openjdk.java.net/jdk/hs/rev/791d551bcdb8 +#if PNG_POWERPC_VSX_OPT > 0 +# define PNG_FILTER_OPTIMIZATIONS png_init_filter_functions_vsx +# define PNG_POWERPC_VSX_IMPLEMENTATION 1 +#endif Causes build errors in our linuxppc64le openjdk jdk-hs (fast)dbg build . We get this linker error : pngrutil.c:(.text+0x4824): undefined reference to `png_init_filter_functions_vsx' Do you have a version of libpng available that contains the missing function png_init_filter_functions_vsx ? Or do you have an idea where it should come from (I cannot find it in the main libpng sources). To fix the build, we could probably disable the part bringing in png_init_filter_functions_vsx in png_init_filter_functions_vsx . Thanks, Matthias Error message : * /hs/support/native/java.desktop/libsplashscreen/pngrutil.o: In function `png_read_filter_row': * pngrutil.c:(.text+0x4824): undefined reference to `png_init_filter_functions_vsx' * collect2: error: ld returned 1 exit status * Awt2dLibraries.gmk:928: recipe for target '/hs/support/modules_libs/java.desktop/libsplashscreen.so' failed -------------- next part -------------- An HTML attachment was scrubbed... URL: From glaubitz at physik.fu-berlin.de Tue Jan 23 13:52:04 2018 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 23 Jan 2018 14:52:04 +0100 Subject: [OpenJDK 2D-Dev] RFR: Bug Pending: Build fails to compile jchuff.c In-Reply-To: References: <2db0bae0-9486-9656-ae83-27b6e28e190b@oracle.com> Message-ID: <77b60641-b0eb-ce7d-fe39-c53808e5e221@physik.fu-berlin.de> On 01/23/2018 02:44 PM, Adam Farley8 wrote: > John: I read your email, and I understand your position. I disagree with it, > but I understand it. 4.8.5 is an old version of gcc, but right now it is the > listed gcc version for SUSE sles on intel, ppc, ppcle, and zLinux. Even if > this is not the case for JDK 10 or 11, we should ensure this fix is fully > propagated to ensure consistent behaviour. > > That is my position. I happen to work at SUSE. And while you're right that SLE-12:GA is on gcc 4.8.x, SLE-12 doesn't have openjdk-9 or openjdk-10 or even -11 in its update repositories (looking at the internal SUSE build system at the moment). openjdk-9 is part of SLE-15:GA which itself ships gcc-7. So, what exactly is the usecase for OpenJDK-9, 10 and 11? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From glaubitz at physik.fu-berlin.de Tue Jan 23 14:20:24 2018 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 23 Jan 2018 15:20:24 +0100 Subject: [OpenJDK 2D-Dev] RFR: Bug Pending: Build fails to compile jchuff.c In-Reply-To: References: <2db0bae0-9486-9656-ae83-27b6e28e190b@oracle.com> <77b60641-b0eb-ce7d-fe39-c53808e5e221@physik.fu-berlin.de> Message-ID: <150d9e88-4d2f-ac07-bacb-bb61eca68f75@physik.fu-berlin.de> On 01/23/2018 03:13 PM, Adam Farley8 wrote: > The URL supplied by David (Holmes) lists 4.8.5 as the gcc version for > building JDK9 on SLES 11.3/12.1. Whether it's in a repository or not, > I read that as "this is the gcc version you should be building JDK9 on". > > https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms > > I asked for this change to be put in 10 and 11 because I don't know the > minimum/recommended gcc version for jdk10 and 11. I'm assuming it's > the same as 9 until told otherwise. Building OpenJDK-10 or OpenJDK-11 requires OpenJDK-9, so you won't be able to build them in a fresh SLE-12:SP3 installation anyway. SLE-11:* doesn't even have OpenJDK-8 and is also going to be out of support next year anyway. I don't necessarily disagree bringing your changes into JDK-8 or JDK-9, but I don't think they make sense to introduce them to JDK-10 and JDK-11. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From glaubitz at physik.fu-berlin.de Tue Jan 23 16:36:59 2018 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 23 Jan 2018 17:36:59 +0100 Subject: [OpenJDK 2D-Dev] RFR: Bug Pending: Build fails to compile jchuff.c In-Reply-To: References: <2db0bae0-9486-9656-ae83-27b6e28e190b@oracle.com> <77b60641-b0eb-ce7d-fe39-c53808e5e221@physik.fu-berlin.de> <150d9e88-4d2f-ac07-bacb-bb61eca68f75@physik.fu-berlin.de> Message-ID: <369e6ee8-bcc8-47b1-1c3b-398ce5aa9ab5@physik.fu-berlin.de> On 01/23/2018 05:25 PM, Adam Farley8 wrote: >> SLE-11:* doesn't even have OpenJDK-8 and is also going to be out of support >> next year anyway. > > Does this mean the gcc version will change? If you have hard information on > this, I'd appreciate the URL. I'm not sure what you mean. SLE12-SP3 ships gcc-4.8.x while SLE-15 will ship gcc-7, see: > https://build.opensuse.org/package/view_file/SUSE:SLE-15:GA/gcc/gcc.spec?expand=1 Is that what you mean when you say the gcc version is changing? > If the minimum gcc version for 10 or 11 is above 4.8.5 across all platforms, > then I agree, but I don't have that information, so I figured I'd ask to > cover all of the JDK versions, to be safe. I don't know what the minimum version is at the moment, to be honest. I haven't tried building OpenJDK-10 or OpenJDK-11 on SLE-12:SP3 yet. I could do that if that's important. > Even if the gcc version does change, adding 4.8.5-specific code shouldn't > break anything. It most likely doesn't break anything. But it leaves workaround in the code base which we could potentially forget to clean out later when it is no longer needed. > What do you think? My opinion is that the codebase for OpenJDK-11 should be kept clean because we are working on getting rid of unnecessary cruft. But this decision isn't up to me, of course. I'm just arguing that I consider the chances that someone will try OpenJDK-11 on SLE-12:SP3 or even SLE-11:SP4 very low. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From adam.farley at uk.ibm.com Tue Jan 23 17:18:28 2018 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Tue, 23 Jan 2018 17:18:28 +0000 Subject: [OpenJDK 2D-Dev] RFR: Bug Pending: Build fails to compile jchuff.c In-Reply-To: <369e6ee8-bcc8-47b1-1c3b-398ce5aa9ab5@physik.fu-berlin.de> References: <2db0bae0-9486-9656-ae83-27b6e28e190b@oracle.com> <77b60641-b0eb-ce7d-fe39-c53808e5e221@physik.fu-berlin.de> <150d9e88-4d2f-ac07-bacb-bb61eca68f75@physik.fu-berlin.de> <369e6ee8-bcc8-47b1-1c3b-398ce5aa9ab5@physik.fu-berlin.de> Message-ID: >On 01/23/2018 05:25 PM, Adam Farley8 wrote: >>> SLE-11:* doesn't even have OpenJDK-8 and is also going to be out of support >>> next year anyway. >> >> Does this mean the gcc version will change? If you have hard information on >> this, I'd appreciate the URL. > >I'm not sure what you mean. SLE12-SP3 ships gcc-4.8.x while SLE-15 will >ship gcc-7, see: > >> https://urldefense.proofpoint.com/v2/url?u=https-3A__build.opensuse.org_package_view-5Ffile_SUSE-3ASLE-2D15-3AGA_gcc_gcc.spec-3Fexpand-3D1&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf-CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=dIGHRmVpTLUCdNXpk5OeZoRTr4KMZfiyFp7leAxQ1x4&s=kvSfKGn4zfKUDx14bZlDZsWrY3uorXE_6lBuTmOMchw&e= > >Is that what you mean when you say the gcc version is changing? Apologies, I was unclear. I was asking if the minimum gcc version on David's website was likely to change when SLE11 went out of service. From what you're telling me, the sles 11 bit on the site will likely be updated to sles 12, and the gcc version won't change (as you're saying SLE12 ships with 4.8.x). > >> If the minimum gcc version for 10 or 11 is above 4.8.5 across all platforms, >> then I agree, but I don't have that information, so I figured I'd ask to >> cover all of the JDK versions, to be safe. > >I don't know what the minimum version is at the moment, to be honest. I haven't >tried building OpenJDK-10 or OpenJDK-11 on SLE-12:SP3 yet. I could do that >if that's important. > >> Even if the gcc version does change, adding 4.8.5-specific code shouldn't >> break anything. > >It most likely doesn't break anything. But it leaves workaround in the code >base which we could potentially forget to clean out later when it is no >longer needed. Agreed. I was hedging my bets on the gcc version not changing. Be good if we had some reliable intel on the minimum gcc version that we could use to make a decision. > >> What do you think? > >My opinion is that the codebase for OpenJDK-11 should be kept clean because >we are working on getting rid of unnecessary cruft. But this decision isn't >up to me, of course. I'm just arguing that I consider the chances that someone >will try OpenJDK-11 on SLE-12:SP3 or even SLE-11:SP4 very low. > >Adrian A reasonable opinion. I may disagree with your conclusions, but you present your arguments well. Could others on this email chain act as tie breaker on the jdk10+11 matter please? Best Regards Adam Farley Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Tue Jan 23 23:12:17 2018 From: philip.race at oracle.com (Philip Race) Date: Tue, 23 Jan 2018 15:12:17 -0800 Subject: [OpenJDK 2D-Dev] RFR: Bug Pending: Build fails to compile jchuff.c In-Reply-To: References: <2db0bae0-9486-9656-ae83-27b6e28e190b@oracle.com> <77b60641-b0eb-ce7d-fe39-c53808e5e221@physik.fu-berlin.de> <150d9e88-4d2f-ac07-bacb-bb61eca68f75@physik.fu-berlin.de> <369e6ee8-bcc8-47b1-1c3b-398ce5aa9ab5@physik.fu-berlin.de> Message-ID: <5A67C151.6050106@oracle.com> The discussion about SLE seems to have taken over. This was originally about zLinux. If it actually makes sense for zLinux for JDK 11 then I have no objections to the proposed toolchain specific patch ... If it does not make sense for 11 then I think you should look only at 8u and prepare a patch directly against that. Its not "critical" for 10 which is in RDP2 already and 9 is going EOSL in less than 3 months ... -phil. On 1/23/18, 9:18 AM, Adam Farley8 wrote: > >On 01/23/2018 05:25 PM, Adam Farley8 wrote: > >>> SLE-11:* doesn't even have OpenJDK-8 and is also going to be out > of support > >>> next year anyway. > >> > >> Does this mean the gcc version will change? If you have hard > information on > >> this, I'd appreciate the URL. > > > >I'm not sure what you mean. SLE12-SP3 ships gcc-4.8.x while SLE-15 will > >ship gcc-7, see: > > > >> > https://urldefense.proofpoint.com/v2/url?u=https-3A__build.opensuse.org_package_view-5Ffile_SUSE-3ASLE-2D15-3AGA_gcc_gcc.spec-3Fexpand-3D1&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf-CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=dIGHRmVpTLUCdNXpk5OeZoRTr4KMZfiyFp7leAxQ1x4&s=kvSfKGn4zfKUDx14bZlDZsWrY3uorXE_6lBuTmOMchw&e= > > > > > >Is that what you mean when you say the gcc version is changing? > > Apologies, I was unclear. I was asking if the minimum gcc version on > David's > website was likely to change when SLE11 went out of service. From what > you're > telling me, the sles 11 bit on the site will likely be updated to sles > 12, > and the gcc version won't change (as you're saying SLE12 ships with > 4.8.x). > > > > >> If the minimum gcc version for 10 or 11 is above 4.8.5 across all > platforms, > >> then I agree, but I don't have that information, so I figured I'd > ask to > >> cover all of the JDK versions, to be safe. > > > >I don't know what the minimum version is at the moment, to be honest. > I haven't > >tried building OpenJDK-10 or OpenJDK-11 on SLE-12:SP3 yet. I could do > that > >if that's important. > > > >> Even if the gcc version does change, adding 4.8.5-specific code > shouldn't > >> break anything. > > > >It most likely doesn't break anything. But it leaves workaround in the > code > >base which we could potentially forget to clean out later when it is no > >longer needed. > > Agreed. I was hedging my bets on the gcc version not changing. Be good > if we had > some reliable intel on the minimum gcc version that we could use to > make a > decision. > > > > >> What do you think? > > > >My opinion is that the codebase for OpenJDK-11 should be kept clean > because > >we are working on getting rid of unnecessary cruft. But this decision > isn't > >up to me, of course. I'm just arguing that I consider the chances that > someone > >will try OpenJDK-11 on SLE-12:SP3 or even SLE-11:SP4 very low. > > > >Adrian > > A reasonable opinion. I may disagree with your conclusions, but you > present > your arguments well. > > Could others on this email chain act as tie breaker on the jdk10+11 > matter please? > > Best Regards > > Adam Farley > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Wed Jan 24 01:59:20 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 24 Jan 2018 11:59:20 +1000 Subject: [OpenJDK 2D-Dev] RFR: Bug Pending: Build fails to compile jchuff.c In-Reply-To: References: <2db0bae0-9486-9656-ae83-27b6e28e190b@oracle.com> <77b60641-b0eb-ce7d-fe39-c53808e5e221@physik.fu-berlin.de> <150d9e88-4d2f-ac07-bacb-bb61eca68f75@physik.fu-berlin.de> <369e6ee8-bcc8-47b1-1c3b-398ce5aa9ab5@physik.fu-berlin.de> Message-ID: <6b6d1846-8d5e-8af0-8813-ad2eb51a38a9@oracle.com> Hi Adam, The wiki: https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms should have been updated for 10, and I expect it will be updated for 11 as we are looking to update all of the "official" tool chains. Given the official gcc version for 9 was already 4.9.2 I don't think it necessary to support 4.8.5 in 10 or 11. Given the new update model it is unclear to me whether it makes sense to make this change in the 9u forest, but at most I think this should only be in 8u and 9u. Thanks, David On 24/01/2018 3:18 AM, Adam Farley8 wrote: >>On 01/23/2018 05:25 PM, Adam Farley8 wrote: >>>> SLE-11:* ?doesn't even have OpenJDK-8 and is also going to be out of support >>>> next year ?anyway. >>> >>> Does this mean the gcc version will change? If you have hard information on >>> this, I'd appreciate the URL. >> >>I'm not sure what you mean. SLE12-SP3 ships gcc-4.8.x while SLE-15 will >>ship gcc-7, see: >> >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__build.opensuse.org_package_view-5Ffile_SUSE-3ASLE-2D15-3AGA_gcc_gcc.spec-3Fexpand-3D1&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf-CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=dIGHRmVpTLUCdNXpk5OeZoRTr4KMZfiyFp7leAxQ1x4&s=kvSfKGn4zfKUDx14bZlDZsWrY3uorXE_6lBuTmOMchw&e= > >> >>Is that what you mean when you say the gcc version is changing? > > Apologies, I was unclear. I was asking if the minimum gcc version on > David's > website was likely to change when SLE11 went out of service. From what > you're > telling me, the sles 11 bit on the site will likely be updated to sles 12, > and the gcc version won't change (as you're saying SLE12 ships with 4.8.x). > >> >>> If the minimum gcc version for 10 or 11 is above 4.8.5 across all platforms, >>> then I agree, but I don't have that information, so I figured I'd ask to >>> cover all of the JDK versions, to be safe. >> >>I don't know what the minimum version is at the moment, to be honest. I haven't >>tried building OpenJDK-10 or OpenJDK-11 on SLE-12:SP3 yet. I could do that >>if that's important. >> >>> Even if the gcc version does change, adding 4.8.5-specific code shouldn't >>> break anything. >> >>It most likely doesn't break anything. But it leaves workaround in the code >>base which we could potentially forget to clean out later when it is no >>longer needed. > > Agreed. I was hedging my bets on the gcc version not changing. Be good > if we had > some reliable intel on the minimum gcc version that we could use to make a > decision. > >> >>> What do you think? >> >>My opinion is that the codebase for OpenJDK-11 should be kept clean because >>we are working on getting rid of unnecessary cruft. But this decision isn't >>up to me, of course. I'm just arguing that I consider the chances that someone >>will try OpenJDK-11 on SLE-12:SP3 or even SLE-11:SP4 very low. >> >>Adrian > > A reasonable opinion. I may disagree with your conclusions, but you present > your arguments well. > > Could others on this email chain act as tie breaker on the jdk10+11 > matter please? > > Best Regards > > Adam Farley > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From Sergey.Bylokhov at oracle.com Thu Jan 25 00:14:03 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 24 Jan 2018 16:14:03 -0800 Subject: [OpenJDK 2D-Dev] [11] RFR JDK-8191023: PngReader throws NegativeArraySizeException when keyword length exceeds chunk size In-Reply-To: <40f28961-ad7b-4bfe-b8aa-a8545e14b283@default> References: <95b1aabc-1c6f-4c11-be71-e06fe83e2dc9@default> <3927fa90-b906-4ad3-b780-20a70d03778e@default> <638b159c-458f-4f87-b3df-fc748ca9dd21@default> <40f28961-ad7b-4bfe-b8aa-a8545e14b283@default> Message-ID: <84e73d3f-d4cc-02ed-67f5-40c1d7aa2d1d@oracle.com> On 22/01/2018 23:17, Prahalad Kumar Narayanan wrote: > My suggestion was to - > . 'Generate' CRC from Chunk data and compare it with the retrieved value at Line 731 'before' proceeding to process any of the chunks. > . In mal-formed chunks (corrupted chunk length /or chunk data), the CRC check will fail thus giving an effective way to identify a valid chunk. > . Many of the if (...) conditions that 've been added to parse_ methods can be avoided with CRC check done upfront. Is it possible that CRC will be broken/malformed as well as a chunk data?(For example if it is generated on top of incorrect data?), if yes then we should check the data itself for correct/incorrect values. -- Best regards, Sergey. From prahalad.kumar.narayanan at oracle.com Thu Jan 25 05:45:05 2018 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Wed, 24 Jan 2018 21:45:05 -0800 (PST) Subject: [OpenJDK 2D-Dev] [11] RFR JDK-8191023: PngReader throws NegativeArraySizeException when keyword length exceeds chunk size In-Reply-To: <84e73d3f-d4cc-02ed-67f5-40c1d7aa2d1d@oracle.com> References: <95b1aabc-1c6f-4c11-be71-e06fe83e2dc9@default> <3927fa90-b906-4ad3-b780-20a70d03778e@default> <638b159c-458f-4f87-b3df-fc748ca9dd21@default> <40f28961-ad7b-4bfe-b8aa-a8545e14b283@default> <84e73d3f-d4cc-02ed-67f5-40c1d7aa2d1d@oracle.com> Message-ID: <77decac9-2982-4c02-95c3-21ee469c6cec@default> Hello Jay Sergey has suggested a valid point- If the CRC was generated with incorrect chunk data, the approach I suggested will succeed and we would still end up in the exception within the parse_ methods. Hence going by if (...) checks is appropriate. Few minor corrections to the webrev.01 are as follows: . Correction to the subtraction value from -2 to -1 in the following lines The original code had -2 because, one extra Unsigned byte was getting read prior to the size calculation. The current changes advance the calculation by a few lines ahead of reading extra UnsignedByte. 431 int compressedProfileLength = chunkLength - keyword.length() - 2; 671 int textLength = chunkLength - keyword.length() - 2; . The result of these two operations are not the same due to the order of execution. If you had checked the logic and corrected the usage, it should be fine. // Original code 518 chunkLength -= metadata.sPLT_paletteName.length() + 1; // Code in the webrev 526 int remainingChunkLength = chunkLength - 527 metadata.sPLT_paletteName.length() + 1; . All the if conditions in the proposed fix check whether remSize < 0. I believe, we will need size "<=" 0 check. Reason is that new [0] will succeed but subsequent read with stream.read* method will throw "ArrayIndexOutOfBounds: 0" exception. Thank you Have a good day Prahalad N. -----Original Message----- From: Sergey Bylokhov Sent: Thursday, January 25, 2018 5:44 AM To: Prahalad Kumar Narayanan; Jayathirth D V; 2d-dev Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-8191023: PngReader throws NegativeArraySizeException when keyword length exceeds chunk size On 22/01/2018 23:17, Prahalad Kumar Narayanan wrote: > My suggestion was to - > . 'Generate' CRC from Chunk data and compare it with the retrieved value at Line 731 'before' proceeding to process any of the chunks. > . In mal-formed chunks (corrupted chunk length /or chunk data), the CRC check will fail thus giving an effective way to identify a valid chunk. > . Many of the if (...) conditions that 've been added to parse_ methods can be avoided with CRC check done upfront. Is it possible that CRC will be broken/malformed as well as a chunk data?(For example if it is generated on top of incorrect data?), if yes then we should check the data itself for correct/incorrect values. -- Best regards, Sergey. From prahalad.kumar.narayanan at oracle.com Thu Jan 25 09:53:02 2018 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Thu, 25 Jan 2018 01:53:02 -0800 (PST) Subject: [OpenJDK 2D-Dev] [11] RFR JDK-8191023: PngReader throws NegativeArraySizeException when keyword length exceeds chunk size In-Reply-To: <77decac9-2982-4c02-95c3-21ee469c6cec@default> References: <95b1aabc-1c6f-4c11-be71-e06fe83e2dc9@default> <3927fa90-b906-4ad3-b780-20a70d03778e@default> <638b159c-458f-4f87-b3df-fc748ca9dd21@default> <40f28961-ad7b-4bfe-b8aa-a8545e14b283@default> <84e73d3f-d4cc-02ed-67f5-40c1d7aa2d1d@oracle.com> <77decac9-2982-4c02-95c3-21ee469c6cec@default> Message-ID: Hello Jay Kindly ignore the point mentioned below with ( >) when you follow-up. Lines 431 and 671 in webrev.01 are correct and we needn't change subtraction value. > Correction to the subtraction value from -2 to -1 in the following lines > 431 int compressedProfileLength = chunkLength - keyword.length() - 2; > 671 int textLength = chunkLength - keyword.length() - 2; Thanks Have a good day Prahalad N. -----Original Message----- From: Prahalad Kumar Narayanan Sent: Thursday, January 25, 2018 11:15 AM To: Sergey Bylokhov; Jayathirth D V; 2d-dev Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-8191023: PngReader throws NegativeArraySizeException when keyword length exceeds chunk size Hello Jay Sergey has suggested a valid point- If the CRC was generated with incorrect chunk data, the approach I suggested will succeed and we would still end up in the exception within the parse_ methods. Hence going by if (...) checks is appropriate. Few minor corrections to the webrev.01 are as follows: . Correction to the subtraction value from -2 to -1 in the following lines The original code had -2 because, one extra Unsigned byte was getting read prior to the size calculation. The current changes advance the calculation by a few lines ahead of reading extra UnsignedByte. 431 int compressedProfileLength = chunkLength - keyword.length() - 2; 671 int textLength = chunkLength - keyword.length() - 2; . The result of these two operations are not the same due to the order of execution. If you had checked the logic and corrected the usage, it should be fine. // Original code 518 chunkLength -= metadata.sPLT_paletteName.length() + 1; // Code in the webrev 526 int remainingChunkLength = chunkLength - 527 metadata.sPLT_paletteName.length() + 1; . All the if conditions in the proposed fix check whether remSize < 0. I believe, we will need size "<=" 0 check. Reason is that new [0] will succeed but subsequent read with stream.read* method will throw "ArrayIndexOutOfBounds: 0" exception. Thank you Have a good day Prahalad N. -----Original Message----- From: Sergey Bylokhov Sent: Thursday, January 25, 2018 5:44 AM To: Prahalad Kumar Narayanan; Jayathirth D V; 2d-dev Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-8191023: PngReader throws NegativeArraySizeException when keyword length exceeds chunk size On 22/01/2018 23:17, Prahalad Kumar Narayanan wrote: > My suggestion was to - > . 'Generate' CRC from Chunk data and compare it with the retrieved value at Line 731 'before' proceeding to process any of the chunks. > . In mal-formed chunks (corrupted chunk length /or chunk data), the CRC check will fail thus giving an effective way to identify a valid chunk. > . Many of the if (...) conditions that 've been added to parse_ methods can be avoided with CRC check done upfront. Is it possible that CRC will be broken/malformed as well as a chunk data?(For example if it is generated on top of incorrect data?), if yes then we should check the data itself for correct/incorrect values. -- Best regards, Sergey. From jayathirth.d.v at oracle.com Thu Jan 25 14:02:22 2018 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 25 Jan 2018 06:02:22 -0800 (PST) Subject: [OpenJDK 2D-Dev] [11] RFR JDK-8191023: PngReader throws NegativeArraySizeException when keyword length exceeds chunk size In-Reply-To: References: <95b1aabc-1c6f-4c11-be71-e06fe83e2dc9@default> <3927fa90-b906-4ad3-b780-20a70d03778e@default> <638b159c-458f-4f87-b3df-fc748ca9dd21@default> <40f28961-ad7b-4bfe-b8aa-a8545e14b283@default> <84e73d3f-d4cc-02ed-67f5-40c1d7aa2d1d@oracle.com> <77decac9-2982-4c02-95c3-21ee469c6cec@default> Message-ID: <7d11e606-a845-4c4b-bd0b-0372df748aca@default> Hi Sergey & Prahalad, Thanks for your inputs. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/8191023/webrev.02/ Regards, Jay -----Original Message----- From: Prahalad Kumar Narayanan Sent: Thursday, January 25, 2018 3:23 PM To: Sergey Bylokhov; Jayathirth D V; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-8191023: PngReader throws NegativeArraySizeException when keyword length exceeds chunk size Hello Jay Kindly ignore the point mentioned below with ( >) when you follow-up. Lines 431 and 671 in webrev.01 are correct and we needn't change subtraction value. > Correction to the subtraction value from -2 to -1 in the following lines > 431 int compressedProfileLength = chunkLength - keyword.length() - 2; > 671 int textLength = chunkLength - keyword.length() - 2; Thanks Have a good day Prahalad N. -----Original Message----- From: Prahalad Kumar Narayanan Sent: Thursday, January 25, 2018 11:15 AM To: Sergey Bylokhov; Jayathirth D V; 2d-dev Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-8191023: PngReader throws NegativeArraySizeException when keyword length exceeds chunk size Hello Jay Sergey has suggested a valid point- If the CRC was generated with incorrect chunk data, the approach I suggested will succeed and we would still end up in the exception within the parse_ methods. Hence going by if (...) checks is appropriate. Few minor corrections to the webrev.01 are as follows: . Correction to the subtraction value from -2 to -1 in the following lines The original code had -2 because, one extra Unsigned byte was getting read prior to the size calculation. The current changes advance the calculation by a few lines ahead of reading extra UnsignedByte. 431 int compressedProfileLength = chunkLength - keyword.length() - 2; 671 int textLength = chunkLength - keyword.length() - 2; . The result of these two operations are not the same due to the order of execution. If you had checked the logic and corrected the usage, it should be fine. // Original code 518 chunkLength -= metadata.sPLT_paletteName.length() + 1; // Code in the webrev 526 int remainingChunkLength = chunkLength - 527 metadata.sPLT_paletteName.length() + 1; . All the if conditions in the proposed fix check whether remSize < 0. I believe, we will need size "<=" 0 check. Reason is that new [0] will succeed but subsequent read with stream.read* method will throw "ArrayIndexOutOfBounds: 0" exception. Thank you Have a good day Prahalad N. -----Original Message----- From: Sergey Bylokhov Sent: Thursday, January 25, 2018 5:44 AM To: Prahalad Kumar Narayanan; Jayathirth D V; 2d-dev Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-8191023: PngReader throws NegativeArraySizeException when keyword length exceeds chunk size On 22/01/2018 23:17, Prahalad Kumar Narayanan wrote: > My suggestion was to - > . 'Generate' CRC from Chunk data and compare it with the retrieved value at Line 731 'before' proceeding to process any of the chunks. > . In mal-formed chunks (corrupted chunk length /or chunk data), the CRC check will fail thus giving an effective way to identify a valid chunk. > . Many of the if (...) conditions that 've been added to parse_ methods can be avoided with CRC check done upfront. Is it possible that CRC will be broken/malformed as well as a chunk data?(For example if it is generated on top of incorrect data?), if yes then we should check the data itself for correct/incorrect values. -- Best regards, Sergey. From Bill.York at mathworks.com Thu Jan 25 21:31:28 2018 From: Bill.York at mathworks.com (Bill York) Date: Thu, 25 Jan 2018 21:31:28 +0000 Subject: [OpenJDK 2D-Dev] bug 8146238 - Java Queue Flusher on MacOS Message-ID: <1EE971F1-5C0B-4C31-9B22-571258989BD0@contoso.com> Hello 2D dev team! I?m looking for help with the bug captured as 8146238. Our customers use Java 8 and on the Mac and this bug is creating a lot of trouble for them. It appears there is a fix proposed: http://cr.openjdk.java.net/~avu/JDK-8146238/webrev.00/ I?ve tried this fix in a recent local build of OpenJDK and it appears to resolve the crash. Could someone let me know if there are plans to fix this bug? 1. In the OpenJDK code base? 2. In the Oracle JDK? Thanks in advance! Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu Jan 25 22:40:04 2018 From: philip.race at oracle.com (Philip Race) Date: Thu, 25 Jan 2018 14:40:04 -0800 Subject: [OpenJDK 2D-Dev] bug 8146238 - Java Queue Flusher on MacOS In-Reply-To: <1EE971F1-5C0B-4C31-9B22-571258989BD0@contoso.com> References: <1EE971F1-5C0B-4C31-9B22-571258989BD0@contoso.com> Message-ID: <5A6A5CC4.30709@oracle.com> There was a reply to the proposal when it was submitted : http://mail.openjdk.java.net/pipermail/2d-dev/2015-December/006130.html suggesting a different approach, but there was no follow-up. So I don't really know what the current status is .. and that was a long time ago. -phil. On 1/25/18, 1:31 PM, Bill York wrote: > > Hello 2D dev team! > > I?m looking for help with the bug captured as 8146238 > . Our customers use > Java 8 and on the Mac and this bug is creating a lot of trouble for them. > > It appears there is a fix proposed: > > http://cr.openjdk.java.net/~avu/JDK-8146238/webrev.00/ > > > I?ve tried this fix in a recent local build of OpenJDK and it appears > to resolve the crash. > > Could someone let me know if there are plans to fix this bug? > > 1. In the OpenJDK code base? > 2. In the Oracle JDK? > > Thanks in advance! > > Bill > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Thu Jan 25 22:43:28 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 25 Jan 2018 14:43:28 -0800 Subject: [OpenJDK 2D-Dev] bug 8146238 - Java Queue Flusher on MacOS In-Reply-To: <1EE971F1-5C0B-4C31-9B22-571258989BD0@contoso.com> References: <1EE971F1-5C0B-4C31-9B22-571258989BD0@contoso.com> Message-ID: <3d6e6a58-6665-ad20-47f3-63152be52852@oracle.com> FYI: Review for those fix was not completed: http://mail.openjdk.java.net/pipermail/2d-dev/2015-December/006130.html On 25/01/2018 13:31, Bill York wrote: > Could someone let me know if there are plans to fix this bug? > > 1. In the OpenJDK code base? > 2. In the Oracle JDK? The next release where it can be fixed is jdk11. Maybe Alexey can provide some additional information? -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Thu Jan 25 22:51:30 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 25 Jan 2018 14:51:30 -0800 Subject: [OpenJDK 2D-Dev] [11] RFR JDK-8191023: PngReader throws NegativeArraySizeException when keyword length exceeds chunk size In-Reply-To: <7d11e606-a845-4c4b-bd0b-0372df748aca@default> References: <95b1aabc-1c6f-4c11-be71-e06fe83e2dc9@default> <3927fa90-b906-4ad3-b780-20a70d03778e@default> <638b159c-458f-4f87-b3df-fc748ca9dd21@default> <40f28961-ad7b-4bfe-b8aa-a8545e14b283@default> <84e73d3f-d4cc-02ed-67f5-40c1d7aa2d1d@oracle.com> <77decac9-2982-4c02-95c3-21ee469c6cec@default> <7d11e606-a845-4c4b-bd0b-0372df748aca@default> Message-ID: <72706dd5-fc63-eb26-d0c3-b6c0095bdfcd@oracle.com> Looks fine. On 25/01/2018 06:02, Jayathirth D V wrote: > Hi Sergey & Prahalad, > > Thanks for your inputs. > > Please find updated webrev for review: > http://cr.openjdk.java.net/~jdv/8191023/webrev.02/ > > Regards, > Jay > > -----Original Message----- > From: Prahalad Kumar Narayanan > Sent: Thursday, January 25, 2018 3:23 PM > To: Sergey Bylokhov; Jayathirth D V; 2d-dev > Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-8191023: PngReader throws NegativeArraySizeException when keyword length exceeds chunk size > > Hello Jay > > Kindly ignore the point mentioned below with ( >) when you follow-up. > Lines 431 and 671 in webrev.01 are correct and we needn't change subtraction value. > >> Correction to the subtraction value from -2 to -1 in the following lines >> 431 int compressedProfileLength = chunkLength - keyword.length() - 2; >> 671 int textLength = chunkLength - keyword.length() - 2; > > Thanks > Have a good day > > Prahalad N. > > -----Original Message----- > From: Prahalad Kumar Narayanan > Sent: Thursday, January 25, 2018 11:15 AM > To: Sergey Bylokhov; Jayathirth D V; 2d-dev > Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-8191023: PngReader throws NegativeArraySizeException when keyword length exceeds chunk size > > Hello Jay > > Sergey has suggested a valid point- If the CRC was generated with incorrect chunk data, the approach I suggested will succeed and we would still end up in the exception within the parse_ methods. Hence going by if (...) checks is appropriate. > > Few minor corrections to the webrev.01 are as follows: > > . Correction to the subtraction value from -2 to -1 in the following lines > The original code had -2 because, one extra Unsigned byte was getting read prior to the size calculation. > The current changes advance the calculation by a few lines ahead of reading extra UnsignedByte. > > 431 int compressedProfileLength = chunkLength - keyword.length() - 2; > 671 int textLength = chunkLength - keyword.length() - 2; > > . The result of these two operations are not the same due to the order of execution. > If you had checked the logic and corrected the usage, it should be fine. > > // Original code > 518 chunkLength -= metadata.sPLT_paletteName.length() + 1; > // Code in the webrev > 526 int remainingChunkLength = chunkLength - > 527 metadata.sPLT_paletteName.length() + 1; > > . All the if conditions in the proposed fix check whether remSize < 0. I believe, we will need size "<=" 0 check. > Reason is that new [0] will succeed but subsequent read with stream.read* method will throw "ArrayIndexOutOfBounds: 0" exception. > > Thank you > Have a good day > > Prahalad N. > > > -----Original Message----- > From: Sergey Bylokhov > Sent: Thursday, January 25, 2018 5:44 AM > To: Prahalad Kumar Narayanan; Jayathirth D V; 2d-dev > Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-8191023: PngReader throws NegativeArraySizeException when keyword length exceeds chunk size > > On 22/01/2018 23:17, Prahalad Kumar Narayanan wrote: >> My suggestion was to - >> . 'Generate' CRC from Chunk data and compare it with the retrieved value at Line 731 'before' proceeding to process any of the chunks. >> . In mal-formed chunks (corrupted chunk length /or chunk data), the CRC check will fail thus giving an effective way to identify a valid chunk. >> . Many of the if (...) conditions that 've been added to parse_ methods can be avoided with CRC check done upfront. > > Is it possible that CRC will be broken/malformed as well as a chunk data?(For example if it is generated on top of incorrect data?), if yes then we should check the data itself for correct/incorrect values. > > -- > Best regards, Sergey. > -- Best regards, Sergey. From Bill.York at mathworks.com Thu Jan 25 22:52:49 2018 From: Bill.York at mathworks.com (Bill York) Date: Thu, 25 Jan 2018 22:52:49 +0000 Subject: [OpenJDK 2D-Dev] bug 8146238 - Java Queue Flusher on MacOS In-Reply-To: <3d6e6a58-6665-ad20-47f3-63152be52852@oracle.com> References: <1EE971F1-5C0B-4C31-9B22-571258989BD0@contoso.com> <3d6e6a58-6665-ad20-47f3-63152be52852@oracle.com> Message-ID: <87619E58-AB61-47E8-9E2F-89D92AB8BD61@mathworks.com> Thanks for the update. We have numerous JDK8 users experiencing this crash. Is JDK11 the only possible resolution? Does anyone know of a work-around? Thanks again, Bill On 1/25/18, 5:48 PM, "Sergey Bylokhov" wrote: FYI: Review for those fix was not completed: http://mail.openjdk.java.net/pipermail/2d-dev/2015-December/006130.html On 25/01/2018 13:31, Bill York wrote: > Could someone let me know if there are plans to fix this bug? > > 1. In the OpenJDK code base? > 2. In the Oracle JDK? The next release where it can be fixed is jdk11. Maybe Alexey can provide some additional information? -- Best regards, Sergey. From prahalad.kumar.narayanan at oracle.com Fri Jan 26 02:58:33 2018 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Thu, 25 Jan 2018 18:58:33 -0800 (PST) Subject: [OpenJDK 2D-Dev] [11] RFR JDK-8191023: PngReader throws NegativeArraySizeException when keyword length exceeds chunk size In-Reply-To: <7d11e606-a845-4c4b-bd0b-0372df748aca@default> References: <95b1aabc-1c6f-4c11-be71-e06fe83e2dc9@default> <3927fa90-b906-4ad3-b780-20a70d03778e@default> <638b159c-458f-4f87-b3df-fc748ca9dd21@default> <40f28961-ad7b-4bfe-b8aa-a8545e14b283@default> <84e73d3f-d4cc-02ed-67f5-40c1d7aa2d1d@oracle.com> <77decac9-2982-4c02-95c3-21ee469c6cec@default> <7d11e606-a845-4c4b-bd0b-0372df748aca@default> Message-ID: <0fc71475-f08a-4b43-be0f-9322dcb2ed18@default> Hello Jay The changes look good. Thanks Have a good day Prahalad N. -----Original Message----- From: Jayathirth D V Sent: Thursday, January 25, 2018 7:32 PM To: Prahalad Kumar Narayanan; Sergey Bylokhov; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-8191023: PngReader throws NegativeArraySizeException when keyword length exceeds chunk size Hi Sergey & Prahalad, Thanks for your inputs. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/8191023/webrev.02/ Regards, Jay -----Original Message----- From: Prahalad Kumar Narayanan Sent: Thursday, January 25, 2018 3:23 PM To: Sergey Bylokhov; Jayathirth D V; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-8191023: PngReader throws NegativeArraySizeException when keyword length exceeds chunk size Hello Jay Kindly ignore the point mentioned below with ( >) when you follow-up. Lines 431 and 671 in webrev.01 are correct and we needn't change subtraction value. > Correction to the subtraction value from -2 to -1 in the following lines > 431 int compressedProfileLength = chunkLength - keyword.length() - 2; > 671 int textLength = chunkLength - keyword.length() - 2; Thanks Have a good day Prahalad N. -----Original Message----- From: Prahalad Kumar Narayanan Sent: Thursday, January 25, 2018 11:15 AM To: Sergey Bylokhov; Jayathirth D V; 2d-dev Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-8191023: PngReader throws NegativeArraySizeException when keyword length exceeds chunk size Hello Jay Sergey has suggested a valid point- If the CRC was generated with incorrect chunk data, the approach I suggested will succeed and we would still end up in the exception within the parse_ methods. Hence going by if (...) checks is appropriate. Few minor corrections to the webrev.01 are as follows: . Correction to the subtraction value from -2 to -1 in the following lines The original code had -2 because, one extra Unsigned byte was getting read prior to the size calculation. The current changes advance the calculation by a few lines ahead of reading extra UnsignedByte. 431 int compressedProfileLength = chunkLength - keyword.length() - 2; 671 int textLength = chunkLength - keyword.length() - 2; . The result of these two operations are not the same due to the order of execution. If you had checked the logic and corrected the usage, it should be fine. // Original code 518 chunkLength -= metadata.sPLT_paletteName.length() + 1; // Code in the webrev 526 int remainingChunkLength = chunkLength - 527 metadata.sPLT_paletteName.length() + 1; . All the if conditions in the proposed fix check whether remSize < 0. I believe, we will need size "<=" 0 check. Reason is that new [0] will succeed but subsequent read with stream.read* method will throw "ArrayIndexOutOfBounds: 0" exception. Thank you Have a good day Prahalad N. -----Original Message----- From: Sergey Bylokhov Sent: Thursday, January 25, 2018 5:44 AM To: Prahalad Kumar Narayanan; Jayathirth D V; 2d-dev Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-8191023: PngReader throws NegativeArraySizeException when keyword length exceeds chunk size On 22/01/2018 23:17, Prahalad Kumar Narayanan wrote: > My suggestion was to - > . 'Generate' CRC from Chunk data and compare it with the retrieved value at Line 731 'before' proceeding to process any of the chunks. > . In mal-formed chunks (corrupted chunk length /or chunk data), the CRC check will fail thus giving an effective way to identify a valid chunk. > . Many of the if (...) conditions that 've been added to parse_ methods can be avoided with CRC check done upfront. Is it possible that CRC will be broken/malformed as well as a chunk data?(For example if it is generated on top of incorrect data?), if yes then we should check the data itself for correct/incorrect values. -- Best regards, Sergey. From alexey.ushakov at jetbrains.com Fri Jan 26 10:23:17 2018 From: alexey.ushakov at jetbrains.com (Alexey Ushakov) Date: Fri, 26 Jan 2018 13:23:17 +0300 Subject: [OpenJDK 2D-Dev] bug 8146238 - Java Queue Flusher on MacOS In-Reply-To: <3d6e6a58-6665-ad20-47f3-63152be52852@oracle.com> References: <1EE971F1-5C0B-4C31-9B22-571258989BD0@contoso.com> <3d6e6a58-6665-ad20-47f3-63152be52852@oracle.com> Message-ID: Hello Sergey, I?ve spent some time looking for the information that you?ve requested in the review but then was distracted by some other important tasks. Actually, the proposed fix is used in our production since then and we haven?t heard any problems with it. If you have a better way to fix the problem we?ll be happy to replace the existing solution. Best Regards, Alexey > On 26 Jan 2018, at 01:43, Sergey Bylokhov wrote: > > FYI: Review for those fix was not completed: > http://mail.openjdk.java.net/pipermail/2d-dev/2015-December/006130.html > > On 25/01/2018 13:31, Bill York wrote: >> Could someone let me know if there are plans to fix this bug? >> 1. In the OpenJDK code base? >> 2. In the Oracle JDK? > > The next release where it can be fixed is jdk11. > Maybe Alexey can provide some additional information? > > -- > Best regards, Sergey. From alexey.ushakov at jetbrains.com Fri Jan 26 10:52:58 2018 From: alexey.ushakov at jetbrains.com (Alexey Ushakov) Date: Fri, 26 Jan 2018 13:52:58 +0300 Subject: [OpenJDK 2D-Dev] bug 8146238 - Java Queue Flusher on MacOS In-Reply-To: <87619E58-AB61-47E8-9E2F-89D92AB8BD61@mathworks.com> References: <1EE971F1-5C0B-4C31-9B22-571258989BD0@contoso.com> <3d6e6a58-6665-ad20-47f3-63152be52852@oracle.com> <87619E58-AB61-47E8-9E2F-89D92AB8BD61@mathworks.com> Message-ID: <2254817D-1678-431E-BBDB-B0657CBDC7E6@jetbrains.com> Hello Bill, You can try our production bits (https://bintray.com/jetbrains/intellij-jdk/download_file?file_path=jbsdk8u152b1136.5_osx_x64.tar.gz) Best Regards, Alexey > On 26 Jan 2018, at 01:52, Bill York wrote: > > Thanks for the update. We have numerous JDK8 users experiencing this crash. > > Is JDK11 the only possible resolution? > > Does anyone know of a work-around? > > Thanks again, > > Bill > > > On 1/25/18, 5:48 PM, "Sergey Bylokhov" wrote: > > FYI: Review for those fix was not completed: > http://mail.openjdk.java.net/pipermail/2d-dev/2015-December/006130.html > > On 25/01/2018 13:31, Bill York wrote: >> Could someone let me know if there are plans to fix this bug? >> >> 1. In the OpenJDK code base? >> 2. In the Oracle JDK? > > The next release where it can be fixed is jdk11. > Maybe Alexey can provide some additional information? > > -- > Best regards, Sergey. > > From sgehwolf at redhat.com Fri Jan 26 16:10:50 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 26 Jan 2018 17:10:50 +0100 Subject: [OpenJDK 2D-Dev] RFR: JDK-8196218: [linux] libfontmanager should be linked against headless awt library Message-ID: <1516983050.4518.21.camel@redhat.com> Hi, Could I please get a review for this rather small patch which originally occurred for us on JDK 8 (Fedora) which recently switched to building with "-Wl,-z,defs" linker flags. The result was a build failure, due to unresolved symbols. Indeed libfontmanager.so should have -lawt_headless in the list of dependent libs as symbols such as AWTLoadFont come from libawt_headless.so, not libawt.so on Linux. Some more details are on the bug. webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8196218 Testing: Build fails with configure option --with-extra-ldflags="-Xlinker -z -Xlinker defs" prior the fix. Succeeds after. Question for 2d-folks/build-dev folks: There is this snippet in the libfontmanager block in make/lib/Awt2dLibraries.gmk, line 686: LDFLAGS := $(subst -Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB)) $(LDFLAGS_CXX_JDK) \ $(call SET_SHARED_LIBRARY_ORIGIN), \ It's my understanding that this is supposed to filter "-Wl,-z,defs" from LDFLAGS_JDKLIB. Does anybody know why it does so? Is there a legit reason when unresolved symbols at link time are OK? Besides, why does it not also filter "-Xlinker -z -Xlinker defs"? FWIW, in JDK 8 it's the other way round. Xlinker flags are filtered, but -Wl,-z,defs is not. Thoughts? Thanks, Severin From erik.joelsson at oracle.com Fri Jan 26 16:27:35 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 26 Jan 2018 08:27:35 -0800 Subject: [OpenJDK 2D-Dev] RFR: JDK-8196218: [linux] libfontmanager should be linked against headless awt library In-Reply-To: <1516983050.4518.21.camel@redhat.com> References: <1516983050.4518.21.camel@redhat.com> Message-ID: Hello Severin, If adding the -lawt_headless makes the code compile with -Wl,-z,defs, then I would also like to see that filtering removed in the same patch. However, I think someone from 2d needs to shed some light on the origin of this. I would assume that at some point there was a reason for not adding -lawt_headless to libfontmanager, and for that to work, someone removed the -Wl,-z,defs from that linker command line. Tracing this back, the removal of -z defs was there in the initial Mercurial commit, so someone needs to go back into the really old archives to find answers here. Regarding -Xlinker vs -Wl, I believe we tried to unify usage to one or the other at some point. /Erik On 2018-01-26 08:10, Severin Gehwolf wrote: > Hi, > > Could I please get a review for this rather small patch which > originally occurred for us on JDK 8 (Fedora) which recently switched to > building with "-Wl,-z,defs" linker flags. The result was a build > failure, due to unresolved symbols. Indeed libfontmanager.so should > have -lawt_headless in the list of dependent libs as symbols such as > AWTLoadFont come from libawt_headless.so, not libawt.so on Linux. Some > more details are on the bug. > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8196218 > > Testing: Build fails with configure option > --with-extra-ldflags="-Xlinker -z -Xlinker defs" > prior the fix. Succeeds after. > > Question for 2d-folks/build-dev folks: > > There is this snippet in the libfontmanager block in > make/lib/Awt2dLibraries.gmk, line 686: > > LDFLAGS := $(subst -Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB)) $(LDFLAGS_CXX_JDK) \ > $(call SET_SHARED_LIBRARY_ORIGIN), \ > > It's my understanding that this is supposed to filter "-Wl,-z,defs" > from LDFLAGS_JDKLIB. Does anybody know why it does so? Is there a legit > reason when unresolved symbols at link time are OK? Besides, why does > it not also filter "-Xlinker -z -Xlinker defs"? FWIW, in JDK 8 it's the > other way round. Xlinker flags are filtered, but -Wl,-z,defs is not. > Thoughts? > > Thanks, > Severin From philip.race at oracle.com Fri Jan 26 16:44:05 2018 From: philip.race at oracle.com (Phil Race) Date: Fri, 26 Jan 2018 08:44:05 -0800 Subject: [OpenJDK 2D-Dev] RFR: JDK-8196218: [linux] libfontmanager should be linked against headless awt library In-Reply-To: <1516983050.4518.21.camel@redhat.com> References: <1516983050.4518.21.camel@redhat.com> Message-ID: <6c63d26a-a056-99bd-c383-146784a4871c@oracle.com> When this was fixed for Solaris https://bugs.openjdk.java.net/browse/JDK-8071710 the observed problem was not building (although it could have been) but at runtime. I think you can verify what you've done with "ldd" .. This patch adds awt_headless.so, but does not remove awt.so. Perhaps the line LIBS_unix := -lawt -ljava -ljvm $(LIBM) $(LIBCXX) After your fix I expect "ldd" should not need to show awt .. just awt_headless ie linux should not have this -lawt dependency any more and the -lawt dependency should be specific to windows + mac .. On 01/26/2018 08:10 AM, Severin Gehwolf wrote: > Hi, > > Could I please get a review for this rather small patch which > originally occurred for us on JDK 8 (Fedora) which recently switched to > building with "-Wl,-z,defs" linker flags. The result was a build > failure, due to unresolved symbols. Indeed libfontmanager.so should > have -lawt_headless in the list of dependent libs as symbols such as > AWTLoadFont come from libawt_headless.so, not libawt.so on Linux. Some > more details are on the bug. > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8196218 > > Testing: Build fails with configure option > --with-extra-ldflags="-Xlinker -z -Xlinker defs" > prior the fix. Succeeds after. > > Question for 2d-folks/build-dev folks: I don't know about this, build folks probably know. -phil. > There is this snippet in the libfontmanager block in > make/lib/Awt2dLibraries.gmk, line 686: > > LDFLAGS := $(subst -Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB)) $(LDFLAGS_CXX_JDK) \ > $(call SET_SHARED_LIBRARY_ORIGIN), \ > > It's my understanding that this is supposed to filter "-Wl,-z,defs" > from LDFLAGS_JDKLIB. Does anybody know why it does so? Is there a legit > reason when unresolved symbols at link time are OK? Besides, why does > it not also filter "-Xlinker -z -Xlinker defs"? FWIW, in JDK 8 it's the > other way round. Xlinker flags are filtered, but -Wl,-z,defs is not. > Thoughts? > > Thanks, > Severin From sgehwolf at redhat.com Fri Jan 26 16:53:31 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 26 Jan 2018 17:53:31 +0100 Subject: [OpenJDK 2D-Dev] RFR: JDK-8196218: [linux] libfontmanager should be linked against headless awt library In-Reply-To: References: <1516983050.4518.21.camel@redhat.com> Message-ID: <1516985611.4518.28.camel@redhat.com> Hi Erik, Thanks for the feedback! On Fri, 2018-01-26 at 08:27 -0800, Erik Joelsson wrote: > Hello Severin, > > If adding the -lawt_headless makes the code compile with -Wl,-z,defs, > then I would also like to see that filtering removed in the same patch. Agreed. > However, I think someone from 2d needs to shed some light on the origin > of this. I would assume that at some point there was a reason for not > adding -lawt_headless to libfontmanager, and for that to work, someone > removed the -Wl,-z,defs from that linker command line. Tracing this > back, the removal of -z defs was there in the initial Mercurial commit, > so someone needs to go back into the really old archives to find answers > here. Interested to hear the answer to this. If that's still possible, that is. > Regarding -Xlinker vs -Wl, I believe we tried to unify usage to one or > the other at some point. Fair enough. It's still sub-optimal that it might fail for one variant but not the other. If it's filtering, it should do it for both variants. W discovered this in the first place because the flags that get set are -Wl,-z,defs yet the JDK 8 filter is for -Xlinker. Now with JDK 11 it's the other way around. With that being said, this discussion is a moot point if we can remove this. Thanks, Severin > /Erik > > On 2018-01-26 08:10, Severin Gehwolf wrote: > > Hi, > > > > Could I please get a review for this rather small patch which > > originally occurred for us on JDK 8 (Fedora) which recently switched to > > building with "-Wl,-z,defs" linker flags. The result was a build > > failure, due to unresolved symbols. Indeed libfontmanager.so should > > have -lawt_headless in the list of dependent libs as symbols such as > > AWTLoadFont come from libawt_headless.so, not libawt.so on Linux. Some > > more details are on the bug. > > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196218 > > > > Testing: Build fails with configure option > > --with-extra-ldflags="-Xlinker -z -Xlinker defs" > > prior the fix. Succeeds after. > > > > Question for 2d-folks/build-dev folks: > > > > There is this snippet in the libfontmanager block in > > make/lib/Awt2dLibraries.gmk, line 686: > > > > LDFLAGS := $(subst -Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB)) $(LDFLAGS_CXX_JDK) \ > > $(call SET_SHARED_LIBRARY_ORIGIN), \ > > > > It's my understanding that this is supposed to filter "-Wl,-z,defs" > > from LDFLAGS_JDKLIB. Does anybody know why it does so? Is there a legit > > reason when unresolved symbols at link time are OK? Besides, why does > > it not also filter "-Xlinker -z -Xlinker defs"? FWIW, in JDK 8 it's the > > other way round. Xlinker flags are filtered, but -Wl,-z,defs is not. > > Thoughts? > > > > Thanks, > > Severin > > From erik.joelsson at oracle.com Fri Jan 26 16:54:31 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 26 Jan 2018 08:54:31 -0800 Subject: [OpenJDK 2D-Dev] RFR: JDK-8196218: [linux] libfontmanager should be linked against headless awt library In-Reply-To: <6c63d26a-a056-99bd-c383-146784a4871c@oracle.com> References: <1516983050.4518.21.camel@redhat.com> <6c63d26a-a056-99bd-c383-146784a4871c@oracle.com> Message-ID: On 2018-01-26 08:44, Phil Race wrote: > When this was fixed for Solaris > https://bugs.openjdk.java.net/browse/JDK-8071710 > the observed problem was not building (although it could have been) > but at runtime. > I think you can verify what you've done with "ldd" .. > > This patch adds awt_headless.so, but does not remove awt.so. > > Perhaps the line > > LIBS_unix := -lawt -ljava -ljvm $(LIBM) $(LIBCXX) > After your fix I expect "ldd" should not need to show awt .. just > awt_headless > > ie linux should not have this -lawt dependency any more and the -lawt > dependency should be specific to windows + mac .. > So we already use -lawt_headless on solaris and aix, then I really can't see a reason not to do the same for linux. > > On 01/26/2018 08:10 AM, Severin Gehwolf wrote: >> Hi, >> >> Could I please get a review for this rather small patch which >> originally occurred for us on JDK 8 (Fedora) which recently switched to >> building with "-Wl,-z,defs" linker flags. The result was a build >> failure, due to unresolved symbols. Indeed libfontmanager.so should >> have -lawt_headless in the list of dependent libs as symbols such as >> AWTLoadFont come from libawt_headless.so, not libawt.so on Linux. Some >> more details are on the bug. >> >> webrev: >> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.01/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8196218 >> >> Testing: Build fails with configure option >> ????????? --with-extra-ldflags="-Xlinker -z -Xlinker defs" >> ????????? prior the fix. Succeeds after. >> >> Question for 2d-folks/build-dev folks: > I don't know about this, build folks probably know. > This is from way ahead of my time. The filtering is simply the build-infra way of achieving the same thing as in the old build system. Here is the corresponding code in jdk7: $ hg annotate make/sun/font/Makefile ... ?? 0: # ?? 0: # Created without -z defs on linux ?? 0: # ?? 0: ifeq ($(PLATFORM), linux) ?? 0:?? LDFLAGS_DEFS_OPTION = ?? 0: endif ... /Erik > -phil. >> There is this snippet in the libfontmanager block in >> make/lib/Awt2dLibraries.gmk, line 686: >> >> ???? LDFLAGS := $(subst -Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB)) >> $(LDFLAGS_CXX_JDK) \ >> ???????? $(call SET_SHARED_LIBRARY_ORIGIN), \ >> >> It's my understanding that this is supposed to filter "-Wl,-z,defs" >> from LDFLAGS_JDKLIB. Does anybody know why it does so? Is there a legit >> reason when unresolved symbols at link time are OK? Besides, why does >> it not also filter "-Xlinker -z -Xlinker defs"? FWIW, in JDK 8 it's the >> other way round. Xlinker flags are filtered, but -Wl,-z,defs is not. >> Thoughts? >> >> Thanks, >> Severin > From sgehwolf at redhat.com Fri Jan 26 17:02:22 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 26 Jan 2018 18:02:22 +0100 Subject: [OpenJDK 2D-Dev] RFR: JDK-8196218: [linux] libfontmanager should be linked against headless awt library In-Reply-To: References: <1516983050.4518.21.camel@redhat.com> <6c63d26a-a056-99bd-c383-146784a4871c@oracle.com> Message-ID: <1516986142.4518.31.camel@redhat.com> On Fri, 2018-01-26 at 08:54 -0800, Erik Joelsson wrote: > On 2018-01-26 08:44, Phil Race wrote: > > When this was fixed for Solaris > > https://bugs.openjdk.java.net/browse/JDK-8071710 > > the observed problem was not building (although it could have been) > > but at runtime. > > I think you can verify what you've done with "ldd" .. > > > > This patch adds awt_headless.so, but does not remove awt.so. > > > > Perhaps the line > > > > LIBS_unix := -lawt -ljava -ljvm $(LIBM) $(LIBCXX) > > After your fix I expect "ldd" should not need to show awt .. just > > awt_headless > > > > ie linux should not have this -lawt dependency any more and the -lawt > > dependency should be specific to windows + mac .. Thanks for the review, Phil. I'll post an updated webrev shortly. Any thoughts on the LDFLAGS filtering? Shouldn't this only be done on platforms that need it? solaris, linux, aix should already be fine without filtering. Thanks, Severin > So we already use -lawt_headless on solaris and aix, then I really can't > see a reason not to do the same for linux. > > > > On 01/26/2018 08:10 AM, Severin Gehwolf wrote: > > > Hi, > > > > > > Could I please get a review for this rather small patch which > > > originally occurred for us on JDK 8 (Fedora) which recently switched to > > > building with "-Wl,-z,defs" linker flags. The result was a build > > > failure, due to unresolved symbols. Indeed libfontmanager.so should > > > have -lawt_headless in the list of dependent libs as symbols such as > > > AWTLoadFont come from libawt_headless.so, not libawt.so on Linux. Some > > > more details are on the bug. > > > > > > webrev: > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.01/ > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196218 > > > > > > Testing: Build fails with configure option > > > --with-extra-ldflags="-Xlinker -z -Xlinker defs" > > > prior the fix. Succeeds after. > > > > > > Question for 2d-folks/build-dev folks: > > > > I don't know about this, build folks probably know. > > > > This is from way ahead of my time. The filtering is simply the > build-infra way of achieving the same thing as in the old build system. > Here is the corresponding code in jdk7: > > $ hg annotate make/sun/font/Makefile > ... > 0: # > 0: # Created without -z defs on linux > 0: # > 0: ifeq ($(PLATFORM), linux) > 0: LDFLAGS_DEFS_OPTION = > 0: endif > ... > > /Erik > > > -phil. > > > There is this snippet in the libfontmanager block in > > > make/lib/Awt2dLibraries.gmk, line 686: > > > > > > LDFLAGS := $(subst -Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB)) > > > $(LDFLAGS_CXX_JDK) \ > > > $(call SET_SHARED_LIBRARY_ORIGIN), \ > > > > > > It's my understanding that this is supposed to filter "-Wl,-z,defs" > > > from LDFLAGS_JDKLIB. Does anybody know why it does so? Is there a legit > > > reason when unresolved symbols at link time are OK? Besides, why does > > > it not also filter "-Xlinker -z -Xlinker defs"? FWIW, in JDK 8 it's the > > > other way round. Xlinker flags are filtered, but -Wl,-z,defs is not. > > > Thoughts? > > > > > > Thanks, > > > Severin > > From philip.race at oracle.com Fri Jan 26 17:09:03 2018 From: philip.race at oracle.com (Phil Race) Date: Fri, 26 Jan 2018 09:09:03 -0800 Subject: [OpenJDK 2D-Dev] RFR: JDK-8196218: [linux] libfontmanager should be linked against headless awt library In-Reply-To: References: <1516983050.4518.21.camel@redhat.com> <6c63d26a-a056-99bd-c383-146784a4871c@oracle.com> Message-ID: <54ebc7de-018b-b594-7f96-2d744eb71e8a@oracle.com> And the SCCS history which pre-dates mercurial says it was added by Kelly O'Hair who was the JDK build lead at the time .. so not added by 2D. D 1.86.1.1 07/03/21 18:00:55 ohair 187 185 00007/00000/00163 6537329: Move JdbcOdbc (JDBC-ODBC Bridge) to closed https://bugs.openjdk.java.net/browse/JDK-6537329 There's no (or insufficient for me) clue as to why that change touched 2D/AWTmakefiles. Perhaps something to do with this comment : > the Makefile will be fixed to use the same Linux fake libraries trick on all Unix platforms, -phil. On 01/26/2018 08:54 AM, Erik Joelsson wrote: >>> >>> Testing: Build fails with configure option >>> --with-extra-ldflags="-Xlinker -z -Xlinker defs" >>> prior the fix. Succeeds after. >>> >>> Question for 2d-folks/build-dev folks: >> I don't know about this, build folks probably know. >> > This is from way ahead of my time. The filtering is simply the > build-infra way of achieving the same thing as in the old build > system. Here is the corresponding code in jdk7: > > $ hg annotate make/sun/font/Makefile > ... > 0: # > 0: # Created without -z defs on linux > 0: # > 0: ifeq ($(PLATFORM), linux) > 0: LDFLAGS_DEFS_OPTION = > 0: endif -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Fri Jan 26 17:15:39 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 26 Jan 2018 09:15:39 -0800 Subject: [OpenJDK 2D-Dev] RFR: JDK-8196218: [linux] libfontmanager should be linked against headless awt library In-Reply-To: <1516986142.4518.31.camel@redhat.com> References: <1516983050.4518.21.camel@redhat.com> <6c63d26a-a056-99bd-c383-146784a4871c@oracle.com> <1516986142.4518.31.camel@redhat.com> Message-ID: <44fb0d96-b134-3fba-8ba8-bffa4fd2225f@oracle.com> On 2018-01-26 09:02, Severin Gehwolf wrote: > On Fri, 2018-01-26 at 08:54 -0800, Erik Joelsson wrote: >> On 2018-01-26 08:44, Phil Race wrote: >>> When this was fixed for Solaris >>> https://bugs.openjdk.java.net/browse/JDK-8071710 >>> the observed problem was not building (although it could have been) >>> but at runtime. >>> I think you can verify what you've done with "ldd" .. >>> >>> This patch adds awt_headless.so, but does not remove awt.so. >>> >>> Perhaps the line >>> >>> LIBS_unix := -lawt -ljava -ljvm $(LIBM) $(LIBCXX) >>> After your fix I expect "ldd" should not need to show awt .. just >>> awt_headless >>> >>> ie linux should not have this -lawt dependency any more and the -lawt >>> dependency should be specific to windows + mac .. > Thanks for the review, Phil. I'll post an updated webrev shortly. > > Any thoughts on the LDFLAGS filtering? Shouldn't this only be done on > platforms that need it? solaris, linux, aix should already be fine > without filtering. I would say try removing the filtering. The affected flags are currently only set on linux and solaris. I will do a test build on the latter and see if the filtering is actually needed. /Erik > Thanks, > Severin > >> So we already use -lawt_headless on solaris and aix, then I really can't >> see a reason not to do the same for linux. >>> On 01/26/2018 08:10 AM, Severin Gehwolf wrote: >>>> Hi, >>>> >>>> Could I please get a review for this rather small patch which >>>> originally occurred for us on JDK 8 (Fedora) which recently switched to >>>> building with "-Wl,-z,defs" linker flags. The result was a build >>>> failure, due to unresolved symbols. Indeed libfontmanager.so should >>>> have -lawt_headless in the list of dependent libs as symbols such as >>>> AWTLoadFont come from libawt_headless.so, not libawt.so on Linux. Some >>>> more details are on the bug. >>>> >>>> webrev: >>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.01/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196218 >>>> >>>> Testing: Build fails with configure option >>>> --with-extra-ldflags="-Xlinker -z -Xlinker defs" >>>> prior the fix. Succeeds after. >>>> >>>> Question for 2d-folks/build-dev folks: >>> I don't know about this, build folks probably know. >>> >> This is from way ahead of my time. The filtering is simply the >> build-infra way of achieving the same thing as in the old build system. >> Here is the corresponding code in jdk7: >> >> $ hg annotate make/sun/font/Makefile >> ... >> 0: # >> 0: # Created without -z defs on linux >> 0: # >> 0: ifeq ($(PLATFORM), linux) >> 0: LDFLAGS_DEFS_OPTION = >> 0: endif >> ... >> >> /Erik >> >>> -phil. >>>> There is this snippet in the libfontmanager block in >>>> make/lib/Awt2dLibraries.gmk, line 686: >>>> >>>> LDFLAGS := $(subst -Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB)) >>>> $(LDFLAGS_CXX_JDK) \ >>>> $(call SET_SHARED_LIBRARY_ORIGIN), \ >>>> >>>> It's my understanding that this is supposed to filter "-Wl,-z,defs" >>>> from LDFLAGS_JDKLIB. Does anybody know why it does so? Is there a legit >>>> reason when unresolved symbols at link time are OK? Besides, why does >>>> it not also filter "-Xlinker -z -Xlinker defs"? FWIW, in JDK 8 it's the >>>> other way round. Xlinker flags are filtered, but -Wl,-z,defs is not. >>>> Thoughts? >>>> >>>> Thanks, >>>> Severin >> From erik.joelsson at oracle.com Fri Jan 26 17:16:05 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 26 Jan 2018 09:16:05 -0800 Subject: [OpenJDK 2D-Dev] RFR: JDK-8196218: [linux] libfontmanager should be linked against headless awt library In-Reply-To: <54ebc7de-018b-b594-7f96-2d744eb71e8a@oracle.com> References: <1516983050.4518.21.camel@redhat.com> <6c63d26a-a056-99bd-c383-146784a4871c@oracle.com> <54ebc7de-018b-b594-7f96-2d744eb71e8a@oracle.com> Message-ID: <86a6a856-da8d-6a4c-8041-27b910cc07d8@oracle.com> Interesting, so this was probably just Kelly trying to get things to build. /Erik On 2018-01-26 09:09, Phil Race wrote: > And the SCCS history which pre-dates mercurial says it was added by > Kelly O'Hair > who was the JDK build lead at the time .. so not added by 2D. > > D 1.86.1.1 07/03/21 18:00:55 ohair 187 185????? 00007/00000/00163 > 6537329: Move JdbcOdbc (JDBC-ODBC Bridge) to closed > > https://bugs.openjdk.java.net/browse/JDK-6537329 > > There's no (or insufficient for me) clue as to why that change touched > 2D/AWTmakefiles. > > Perhaps something to do with this comment : > > the Makefile will be fixed to use the same Linux fake libraries > trick on all Unix platforms, > > -phil. > > On 01/26/2018 08:54 AM, Erik Joelsson wrote: >>>> >>>> Testing: Build fails with configure option >>>> ????????? --with-extra-ldflags="-Xlinker -z -Xlinker defs" >>>> ????????? prior the fix. Succeeds after. >>>> >>>> Question for 2d-folks/build-dev folks: >>> I don't know about this, build folks probably know. >>> >> This is from way ahead of my time. The filtering is simply the >> build-infra way of achieving the same thing as in the old build >> system. Here is the corresponding code in jdk7: >> >> $ hg annotate make/sun/font/Makefile >> ... >> ?? 0: # >> ?? 0: # Created without -z defs on linux >> ?? 0: # >> ?? 0: ifeq ($(PLATFORM), linux) >> ?? 0:?? LDFLAGS_DEFS_OPTION = >> ?? 0: endif > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri Jan 26 17:18:37 2018 From: philip.race at oracle.com (Phil Race) Date: Fri, 26 Jan 2018 09:18:37 -0800 Subject: [OpenJDK 2D-Dev] RFR: JDK-8196218: [linux] libfontmanager should be linked against headless awt library In-Reply-To: <1516986142.4518.31.camel@redhat.com> References: <1516983050.4518.21.camel@redhat.com> <6c63d26a-a056-99bd-c383-146784a4871c@oracle.com> <1516986142.4518.31.camel@redhat.com> Message-ID: <299c5eaf-3925-9f79-faf9-ca1c7ad01535@oracle.com> On 01/26/2018 09:02 AM, Severin Gehwolf wrote: > Any thoughts on the LDFLAGS filtering? Shouldn't this only be done on > platforms that need it? solaris, linux, aix should already be fine > without filtering. Only to say I really don't understand it :-) But I think it is historical baggage. Erik said :- > I would assume that at some point there was a reason for not adding -lawt_headless to libfontmanager There was a time (1.4) when ONLY Solaris had a separate headless library. I alluded to this in https://bugs.openjdk.java.net/browse/JDK-8071710 Headless for Linux was added in 1.5. So we may be dealing with some really old technical debt. -phil. From erik.joelsson at oracle.com Fri Jan 26 17:23:41 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 26 Jan 2018 09:23:41 -0800 Subject: [OpenJDK 2D-Dev] RFR: JDK-8196218: [linux] libfontmanager should be linked against headless awt library In-Reply-To: <44fb0d96-b134-3fba-8ba8-bffa4fd2225f@oracle.com> References: <1516983050.4518.21.camel@redhat.com> <6c63d26a-a056-99bd-c383-146784a4871c@oracle.com> <1516986142.4518.31.camel@redhat.com> <44fb0d96-b134-3fba-8ba8-bffa4fd2225f@oracle.com> Message-ID: <2d569244-42a1-c652-cf96-0761d22328bc@oracle.com> This patch builds on Solaris: diff -r 50cd89fe209f make/lib/Awt2dLibraries.gmk --- a/make/lib/Awt2dLibraries.gmk +++ b/make/lib/Awt2dLibraries.gmk @@ -683,15 +683,15 @@ ???????? hidevf w_novirtualdescr arrowrtn2, \ ???? DISABLED_WARNINGS_microsoft := 4267 4244 4018 4090 4996 4146 4334 4819 4101, \ ???? MAPFILE := $(BUILD_LIBFONTMANAGER_MAPFILE), \ -??? LDFLAGS := $(subst -Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB)) $(LDFLAGS_CXX_JDK) \ +??? LDFLAGS := $(LDFLAGS_JDKLIB) $(LDFLAGS_CXX_JDK) \ ???????? $(call SET_SHARED_LIBRARY_ORIGIN), \ ???? LDFLAGS_unix := -L$(INSTALL_LIBRARIES_HERE), \ ???? LDFLAGS_macosx := -undefined dynamic_lookup, \ ???? LIBS := $(BUILD_LIBFONTMANAGER_FONTLIB), \ ???? LIBS_unix := -lawt -ljava -ljvm $(LIBM) $(LIBCXX), \ -??? LIBS_linux := -lc, \ +??? LIBS_linux := -lawt_headless -lc, \ ???? LIBS_solaris := -lawt_headless -lc, \ ???? LIBS_aix := -lawt_headless,\ I could not remove -lawt however. /Erik On 2018-01-26 09:15, Erik Joelsson wrote: > On 2018-01-26 09:02, Severin Gehwolf wrote: >> On Fri, 2018-01-26 at 08:54 -0800, Erik Joelsson wrote: >>> On 2018-01-26 08:44, Phil Race wrote: >>>> When this was fixed for Solaris >>>> https://bugs.openjdk.java.net/browse/JDK-8071710 >>>> the observed problem was not building (although it could have been) >>>> but at runtime. >>>> I think you can verify what you've done with "ldd" .. >>>> >>>> This patch adds awt_headless.so, but does not remove awt.so. >>>> >>>> Perhaps the line >>>> >>>> LIBS_unix := -lawt -ljava -ljvm $(LIBM) $(LIBCXX) >>>> After your fix I expect "ldd" should not need to show awt .. just >>>> awt_headless >>>> >>>> ie linux should not have this -lawt dependency any more and the -lawt >>>> dependency should be specific to windows + mac .. >> Thanks for the review, Phil. I'll post an updated webrev shortly. >> >> Any thoughts on the LDFLAGS filtering? Shouldn't this only be done on >> platforms that need it? solaris, linux, aix should already be fine >> without filtering. > I would say try removing the filtering. The affected flags are > currently only set on linux and solaris. I will do a test build on the > latter and see if the filtering is actually needed. > > /Erik >> Thanks, >> Severin >> >>> So we already use -lawt_headless on solaris and aix, then I really >>> can't >>> see a reason not to do the same for linux. >>>> On 01/26/2018 08:10 AM, Severin Gehwolf wrote: >>>>> Hi, >>>>> >>>>> Could I please get a review for this rather small patch which >>>>> originally occurred for us on JDK 8 (Fedora) which recently >>>>> switched to >>>>> building with "-Wl,-z,defs" linker flags. The result was a build >>>>> failure, due to unresolved symbols. Indeed libfontmanager.so should >>>>> have -lawt_headless in the list of dependent libs as symbols such as >>>>> AWTLoadFont come from libawt_headless.so, not libawt.so on Linux. >>>>> Some >>>>> more details are on the bug. >>>>> >>>>> webrev: >>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.01/ >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196218 >>>>> >>>>> Testing: Build fails with configure option >>>>> ?????????? --with-extra-ldflags="-Xlinker -z -Xlinker defs" >>>>> ?????????? prior the fix. Succeeds after. >>>>> >>>>> Question for 2d-folks/build-dev folks: >>>> I don't know about this, build folks probably know. >>>> >>> This is from way ahead of my time. The filtering is simply the >>> build-infra way of achieving the same thing as in the old build system. >>> Here is the corresponding code in jdk7: >>> >>> $ hg annotate make/sun/font/Makefile >>> ... >>> ???? 0: # >>> ???? 0: # Created without -z defs on linux >>> ???? 0: # >>> ???? 0: ifeq ($(PLATFORM), linux) >>> ???? 0:?? LDFLAGS_DEFS_OPTION = >>> ???? 0: endif >>> ... >>> >>> /Erik >>> >>>> -phil. >>>>> There is this snippet in the libfontmanager block in >>>>> make/lib/Awt2dLibraries.gmk, line 686: >>>>> >>>>> ????? LDFLAGS := $(subst >>>>> -Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB)) >>>>> $(LDFLAGS_CXX_JDK) \ >>>>> ????????? $(call SET_SHARED_LIBRARY_ORIGIN), \ >>>>> >>>>> It's my understanding that this is supposed to filter "-Wl,-z,defs" >>>>> from LDFLAGS_JDKLIB. Does anybody know why it does so? Is there a >>>>> legit >>>>> reason when unresolved symbols at link time are OK? Besides, why does >>>>> it not also filter "-Xlinker -z -Xlinker defs"? FWIW, in JDK 8 >>>>> it's the >>>>> other way round. Xlinker flags are filtered, but -Wl,-z,defs is not. >>>>> Thoughts? >>>>> >>>>> Thanks, >>>>> Severin >>> > From sgehwolf at redhat.com Fri Jan 26 17:28:30 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 26 Jan 2018 18:28:30 +0100 Subject: [OpenJDK 2D-Dev] RFR: JDK-8196218: [linux] libfontmanager should be linked against headless awt library In-Reply-To: <299c5eaf-3925-9f79-faf9-ca1c7ad01535@oracle.com> References: <1516983050.4518.21.camel@redhat.com> <6c63d26a-a056-99bd-c383-146784a4871c@oracle.com> <1516986142.4518.31.camel@redhat.com> <299c5eaf-3925-9f79-faf9-ca1c7ad01535@oracle.com> Message-ID: <1516987710.4518.32.camel@redhat.com> On Fri, 2018-01-26 at 09:18 -0800, Phil Race wrote: > > On 01/26/2018 09:02 AM, Severin Gehwolf wrote: > > Any thoughts on the LDFLAGS filtering? Shouldn't this only be done on > > platforms that need it? solaris, linux, aix should already be fine > > without filtering. > > Only to say I really don't understand it :-) > But I think it is historical baggage. > > > Erik said :- > > I would assume that at some point there was a reason for not adding > -lawt_headless to libfontmanager > > There was a time (1.4) when ONLY Solaris had a separate headless library. > I alluded to this in https://bugs.openjdk.java.net/browse/JDK-8071710 > Headless for Linux was added in 1.5. > > So we may be dealing with some really old technical debt. OK. Thanks, Erik, Phil! Cheers, Severin From philip.race at oracle.com Fri Jan 26 17:44:08 2018 From: philip.race at oracle.com (Phil Race) Date: Fri, 26 Jan 2018 09:44:08 -0800 Subject: [OpenJDK 2D-Dev] RFR: JDK-8196218: [linux] libfontmanager should be linked against headless awt library In-Reply-To: <2d569244-42a1-c652-cf96-0761d22328bc@oracle.com> References: <1516983050.4518.21.camel@redhat.com> <6c63d26a-a056-99bd-c383-146784a4871c@oracle.com> <1516986142.4518.31.camel@redhat.com> <44fb0d96-b134-3fba-8ba8-bffa4fd2225f@oracle.com> <2d569244-42a1-c652-cf96-0761d22328bc@oracle.com> Message-ID: > I could not remove -lawt however. Ah yes, Erik sent me the errors and yes there are some 2D functions that are defined in libawt that fontmanager needs for text rendering support, so we can't remove that. libawt on these platforms with separate headless and xawt libraries could have more aptly be called lib2d .. since most of the true AWT functionality is in the xawt library. -phil. On 01/26/2018 09:23 AM, Erik Joelsson wrote: > This patch builds on Solaris: > > diff -r 50cd89fe209f make/lib/Awt2dLibraries.gmk > --- a/make/lib/Awt2dLibraries.gmk > +++ b/make/lib/Awt2dLibraries.gmk > @@ -683,15 +683,15 @@ > hidevf w_novirtualdescr arrowrtn2, \ > DISABLED_WARNINGS_microsoft := 4267 4244 4018 4090 4996 4146 4334 > 4819 4101, \ > MAPFILE := $(BUILD_LIBFONTMANAGER_MAPFILE), \ > - LDFLAGS := $(subst -Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB)) > $(LDFLAGS_CXX_JDK) \ > + LDFLAGS := $(LDFLAGS_JDKLIB) $(LDFLAGS_CXX_JDK) \ > $(call SET_SHARED_LIBRARY_ORIGIN), \ > LDFLAGS_unix := -L$(INSTALL_LIBRARIES_HERE), \ > LDFLAGS_macosx := -undefined dynamic_lookup, \ > LIBS := $(BUILD_LIBFONTMANAGER_FONTLIB), \ > LIBS_unix := -lawt -ljava -ljvm $(LIBM) $(LIBCXX), \ > - LIBS_linux := -lc, \ > + LIBS_linux := -lawt_headless -lc, \ > LIBS_solaris := -lawt_headless -lc, \ > LIBS_aix := -lawt_headless,\ > > I could not remove -lawt however. > > /Erik > > On 2018-01-26 09:15, Erik Joelsson wrote: >> On 2018-01-26 09:02, Severin Gehwolf wrote: >>> On Fri, 2018-01-26 at 08:54 -0800, Erik Joelsson wrote: >>>> On 2018-01-26 08:44, Phil Race wrote: >>>>> When this was fixed for Solaris >>>>> https://bugs.openjdk.java.net/browse/JDK-8071710 >>>>> the observed problem was not building (although it could have been) >>>>> but at runtime. >>>>> I think you can verify what you've done with "ldd" .. >>>>> >>>>> This patch adds awt_headless.so, but does not remove awt.so. >>>>> >>>>> Perhaps the line >>>>> >>>>> LIBS_unix := -lawt -ljava -ljvm $(LIBM) $(LIBCXX) >>>>> After your fix I expect "ldd" should not need to show awt .. just >>>>> awt_headless >>>>> >>>>> ie linux should not have this -lawt dependency any more and the -lawt >>>>> dependency should be specific to windows + mac .. >>> Thanks for the review, Phil. I'll post an updated webrev shortly. >>> >>> Any thoughts on the LDFLAGS filtering? Shouldn't this only be done on >>> platforms that need it? solaris, linux, aix should already be fine >>> without filtering. >> I would say try removing the filtering. The affected flags are >> currently only set on linux and solaris. I will do a test build on >> the latter and see if the filtering is actually needed. >> >> /Erik >>> Thanks, >>> Severin >>> >>>> So we already use -lawt_headless on solaris and aix, then I really >>>> can't >>>> see a reason not to do the same for linux. >>>>> On 01/26/2018 08:10 AM, Severin Gehwolf wrote: >>>>>> Hi, >>>>>> >>>>>> Could I please get a review for this rather small patch which >>>>>> originally occurred for us on JDK 8 (Fedora) which recently >>>>>> switched to >>>>>> building with "-Wl,-z,defs" linker flags. The result was a build >>>>>> failure, due to unresolved symbols. Indeed libfontmanager.so should >>>>>> have -lawt_headless in the list of dependent libs as symbols such as >>>>>> AWTLoadFont come from libawt_headless.so, not libawt.so on Linux. >>>>>> Some >>>>>> more details are on the bug. >>>>>> >>>>>> webrev: >>>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.01/ >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196218 >>>>>> >>>>>> Testing: Build fails with configure option >>>>>> --with-extra-ldflags="-Xlinker -z -Xlinker defs" >>>>>> prior the fix. Succeeds after. >>>>>> >>>>>> Question for 2d-folks/build-dev folks: >>>>> I don't know about this, build folks probably know. >>>>> >>>> This is from way ahead of my time. The filtering is simply the >>>> build-infra way of achieving the same thing as in the old build >>>> system. >>>> Here is the corresponding code in jdk7: >>>> >>>> $ hg annotate make/sun/font/Makefile >>>> ... >>>> 0: # >>>> 0: # Created without -z defs on linux >>>> 0: # >>>> 0: ifeq ($(PLATFORM), linux) >>>> 0: LDFLAGS_DEFS_OPTION = >>>> 0: endif >>>> ... >>>> >>>> /Erik >>>> >>>>> -phil. >>>>>> There is this snippet in the libfontmanager block in >>>>>> make/lib/Awt2dLibraries.gmk, line 686: >>>>>> >>>>>> LDFLAGS := $(subst >>>>>> -Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB)) >>>>>> $(LDFLAGS_CXX_JDK) \ >>>>>> $(call SET_SHARED_LIBRARY_ORIGIN), \ >>>>>> >>>>>> It's my understanding that this is supposed to filter "-Wl,-z,defs" >>>>>> from LDFLAGS_JDKLIB. Does anybody know why it does so? Is there a >>>>>> legit >>>>>> reason when unresolved symbols at link time are OK? Besides, why >>>>>> does >>>>>> it not also filter "-Xlinker -z -Xlinker defs"? FWIW, in JDK 8 >>>>>> it's the >>>>>> other way round. Xlinker flags are filtered, but -Wl,-z,defs is not. >>>>>> Thoughts? >>>>>> >>>>>> Thanks, >>>>>> Severin >>>> >> > From philip.race at oracle.com Fri Jan 26 23:20:39 2018 From: philip.race at oracle.com (Philip Race) Date: Fri, 26 Jan 2018 15:20:39 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8193483: Update client-libs ProblemList.txt Message-ID: <5A6BB7C7.7010305@oracle.com> bug: https://bugs.openjdk.java.net/browse/JDK-8193483 webrev; http://cr.openjdk.java.net/~prr/8193483/ An update to the ProblemList to exclude most of the tests that fail on Windows. There are still a number of tests that have "errors" like timeouts that need to be added. Also I need to do a pass on mac + linux. Its lengthy and tedious so that won't happen overnight. You can apply this patch before running jtreg yourself so as to minimise failures .. then you can see which tests I've not gotten to .. or which did not fail for me To run the client tests you can do : jtreg -a -ignore:quiet -exclude:test/jdk/ProblemList.txt opem/test/jdk:jdk_desktop -phil. From Sergey.Bylokhov at oracle.com Fri Jan 26 23:34:33 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 26 Jan 2018 15:34:33 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8193483: Update client-libs ProblemList.txt In-Reply-To: <5A6BB7C7.7010305@oracle.com> References: <5A6BB7C7.7010305@oracle.com> Message-ID: <8e86e6ce-0267-e838-948d-5b090e9e445d@oracle.com> Looks fine. On 26/01/2018 15:20, Philip Race wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8193483 > webrev; http://cr.openjdk.java.net/~prr/8193483/ > > An update to the ProblemList to exclude most of the tests that fail on > Windows. > > There are still a number of tests that have "errors" like timeouts that > need to be added. > > Also I need to do a pass on mac + linux. Its lengthy and tedious so that > won't happen overnight. > > You can apply this patch before running jtreg yourself so as to minimise > failures .. > then you can see which tests I've not gotten to .. or which did not fail > for me > > To run the client tests you can do : > > jtreg -a -ignore:quiet -exclude:test/jdk/ProblemList.txt > opem/test/jdk:jdk_desktop > > -phil. -- Best regards, Sergey. From sgehwolf at redhat.com Mon Jan 29 09:39:38 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 29 Jan 2018 10:39:38 +0100 Subject: [OpenJDK 2D-Dev] RFR: JDK-8196218: [linux] libfontmanager should be linked against headless awt library In-Reply-To: References: <1516983050.4518.21.camel@redhat.com> <6c63d26a-a056-99bd-c383-146784a4871c@oracle.com> <1516986142.4518.31.camel@redhat.com> <44fb0d96-b134-3fba-8ba8-bffa4fd2225f@oracle.com> <2d569244-42a1-c652-cf96-0761d22328bc@oracle.com> Message-ID: <1517218778.4106.10.camel@redhat.com> Hi, Updated webrev which removes the linker flags filtering. Linking with the awt lib is being kept. ldd confirmed what Erik found out elsewhere: $ find build/linux-x86_64-normal-server-release/images/jdk -name libfontmanager.so build/linux-x86_64-normal-server-release/images/jdk/lib/libfontmanager.so $ ldd build/linux-x86_64-normal-server-release/images/jdk/lib/libfontmanager.so ldd: warning: you do not have execution permission for `build/linux-x86_64-normal-server-release/images/jdk/lib/libfontmanager.so' linux-vdso.so.1 (0x00007ffe13cc5000) libfreetype.so.6 => /lib64/libfreetype.so.6 (0x00007fb58e204000) libawt.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libawt.so (0x00007fb58df34000) libjava.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libjava.so (0x00007fb58dd07000) libjvm.so => not found libawt_headless.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libawt_headless.so (0x00007fb58dafe000) libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fb58d778000) libm.so.6 => /lib64/libm.so.6 (0x00007fb58d423000) libc.so.6 => /lib64/libc.so.6 (0x00007fb58d040000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fb58ce29000) libbz2.so.1 => /lib64/libbz2.so.1 (0x00007fb58cc18000) libpng16.so.16 => /lib64/libpng16.so.16 (0x00007fb58c9e5000) libz.so.1 => /lib64/libz.so.1 (0x00007fb58c7ce000) libjvm.so => not found libdl.so.2 => /lib64/libdl.so.2 (0x00007fb58c5ca000) libjvm.so => not found libverify.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libverify.so (0x00007fb58c3bb000) /lib64/ld-linux-x86-64.so.2 (0x00007fb58e74f000) libjvm.so => not found libjvm.so => not found http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.02/ How does this look? Do I need an Oracle sponsor for this or can I push this to jdk/jdk myself. Thanks, Severin On Fri, 2018-01-26 at 09:44 -0800, Phil Race wrote: > > I could not remove -lawt however. > > Ah yes, Erik sent me the errors and yes there are some 2D functions that are > defined in libawt that fontmanager needs for text rendering support, so > we can't remove that. > > libawt on these platforms with separate headless and xawt libraries > could have > more aptly be called lib2d .. since most of the true AWT functionality > is in the xawt library. > > > -phil. > > On 01/26/2018 09:23 AM, Erik Joelsson wrote: > > This patch builds on Solaris: > > > > diff -r 50cd89fe209f make/lib/Awt2dLibraries.gmk > > --- a/make/lib/Awt2dLibraries.gmk > > +++ b/make/lib/Awt2dLibraries.gmk > > @@ -683,15 +683,15 @@ > > hidevf w_novirtualdescr arrowrtn2, \ > > DISABLED_WARNINGS_microsoft := 4267 4244 4018 4090 4996 4146 4334 > > 4819 4101, \ > > MAPFILE := $(BUILD_LIBFONTMANAGER_MAPFILE), \ > > - LDFLAGS := $(subst -Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB)) > > $(LDFLAGS_CXX_JDK) \ > > + LDFLAGS := $(LDFLAGS_JDKLIB) $(LDFLAGS_CXX_JDK) \ > > $(call SET_SHARED_LIBRARY_ORIGIN), \ > > LDFLAGS_unix := -L$(INSTALL_LIBRARIES_HERE), \ > > LDFLAGS_macosx := -undefined dynamic_lookup, \ > > LIBS := $(BUILD_LIBFONTMANAGER_FONTLIB), \ > > LIBS_unix := -lawt -ljava -ljvm $(LIBM) $(LIBCXX), \ > > - LIBS_linux := -lc, \ > > + LIBS_linux := -lawt_headless -lc, \ > > LIBS_solaris := -lawt_headless -lc, \ > > LIBS_aix := -lawt_headless,\ > > > > I could not remove -lawt however. > > > > /Erik > > > > On 2018-01-26 09:15, Erik Joelsson wrote: > > > On 2018-01-26 09:02, Severin Gehwolf wrote: > > > > On Fri, 2018-01-26 at 08:54 -0800, Erik Joelsson wrote: > > > > > On 2018-01-26 08:44, Phil Race wrote: > > > > > > When this was fixed for Solaris > > > > > > https://bugs.openjdk.java.net/browse/JDK-8071710 > > > > > > the observed problem was not building (although it could have been) > > > > > > but at runtime. > > > > > > I think you can verify what you've done with "ldd" .. > > > > > > > > > > > > This patch adds awt_headless.so, but does not remove awt.so. > > > > > > > > > > > > Perhaps the line > > > > > > > > > > > > LIBS_unix := -lawt -ljava -ljvm $(LIBM) $(LIBCXX) > > > > > > After your fix I expect "ldd" should not need to show awt .. just > > > > > > awt_headless > > > > > > > > > > > > ie linux should not have this -lawt dependency any more and the -lawt > > > > > > dependency should be specific to windows + mac .. > > > > > > > > Thanks for the review, Phil. I'll post an updated webrev shortly. > > > > > > > > Any thoughts on the LDFLAGS filtering? Shouldn't this only be done on > > > > platforms that need it? solaris, linux, aix should already be fine > > > > without filtering. > > > > > > I would say try removing the filtering. The affected flags are > > > currently only set on linux and solaris. I will do a test build on > > > the latter and see if the filtering is actually needed. > > > > > > /Erik > > > > Thanks, > > > > Severin > > > > > > > > > So we already use -lawt_headless on solaris and aix, then I really > > > > > can't > > > > > see a reason not to do the same for linux. > > > > > > On 01/26/2018 08:10 AM, Severin Gehwolf wrote: > > > > > > > Hi, > > > > > > > > > > > > > > Could I please get a review for this rather small patch which > > > > > > > originally occurred for us on JDK 8 (Fedora) which recently > > > > > > > switched to > > > > > > > building with "-Wl,-z,defs" linker flags. The result was a build > > > > > > > failure, due to unresolved symbols. Indeed libfontmanager.so should > > > > > > > have -lawt_headless in the list of dependent libs as symbols such as > > > > > > > AWTLoadFont come from libawt_headless.so, not libawt.so on Linux. > > > > > > > Some > > > > > > > more details are on the bug. > > > > > > > > > > > > > > webrev: > > > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.01/ > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196218 > > > > > > > > > > > > > > Testing: Build fails with configure option > > > > > > > --with-extra-ldflags="-Xlinker -z -Xlinker defs" > > > > > > > prior the fix. Succeeds after. > > > > > > > > > > > > > > Question for 2d-folks/build-dev folks: > > > > > > > > > > > > I don't know about this, build folks probably know. > > > > > > > > > > > > > > > > This is from way ahead of my time. The filtering is simply the > > > > > build-infra way of achieving the same thing as in the old build > > > > > system. > > > > > Here is the corresponding code in jdk7: > > > > > > > > > > $ hg annotate make/sun/font/Makefile > > > > > ... > > > > > 0: # > > > > > 0: # Created without -z defs on linux > > > > > 0: # > > > > > 0: ifeq ($(PLATFORM), linux) > > > > > 0: LDFLAGS_DEFS_OPTION = > > > > > 0: endif > > > > > ... > > > > > > > > > > /Erik > > > > > > > > > > > -phil. > > > > > > > There is this snippet in the libfontmanager block in > > > > > > > make/lib/Awt2dLibraries.gmk, line 686: > > > > > > > > > > > > > > LDFLAGS := $(subst > > > > > > > -Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB)) > > > > > > > $(LDFLAGS_CXX_JDK) \ > > > > > > > $(call SET_SHARED_LIBRARY_ORIGIN), \ > > > > > > > > > > > > > > It's my understanding that this is supposed to filter "-Wl,-z,defs" > > > > > > > from LDFLAGS_JDKLIB. Does anybody know why it does so? Is there a > > > > > > > legit > > > > > > > reason when unresolved symbols at link time are OK? Besides, why > > > > > > > does > > > > > > > it not also filter "-Xlinker -z -Xlinker defs"? FWIW, in JDK 8 > > > > > > > it's the > > > > > > > other way round. Xlinker flags are filtered, but -Wl,-z,defs is not. > > > > > > > Thoughts? > > > > > > > > > > > > > > Thanks, > > > > > > > Severin > > From erik.joelsson at oracle.com Mon Jan 29 16:29:59 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 29 Jan 2018 08:29:59 -0800 Subject: [OpenJDK 2D-Dev] RFR: JDK-8196218: [linux] libfontmanager should be linked against headless awt library In-Reply-To: <1517218778.4106.10.camel@redhat.com> References: <1516983050.4518.21.camel@redhat.com> <6c63d26a-a056-99bd-c383-146784a4871c@oracle.com> <1516986142.4518.31.camel@redhat.com> <44fb0d96-b134-3fba-8ba8-bffa4fd2225f@oracle.com> <2d569244-42a1-c652-cf96-0761d22328bc@oracle.com> <1517218778.4106.10.camel@redhat.com> Message-ID: <4657791d-45ff-deb6-b092-b3b28963dd4f@oracle.com> This looks good to me. Good catch on the dependency declaration further down. I don't see any reason this would need a sponsor, jdk/jdk should be open. /Erik On 2018-01-29 01:39, Severin Gehwolf wrote: > Hi, > > Updated webrev which removes the linker flags filtering. Linking with > the awt lib is being kept. ldd confirmed what Erik found out elsewhere: > > $ find build/linux-x86_64-normal-server-release/images/jdk -name libfontmanager.so > build/linux-x86_64-normal-server-release/images/jdk/lib/libfontmanager.so > $ ldd build/linux-x86_64-normal-server-release/images/jdk/lib/libfontmanager.so > ldd: warning: you do not have execution permission for `build/linux-x86_64-normal-server-release/images/jdk/lib/libfontmanager.so' > linux-vdso.so.1 (0x00007ffe13cc5000) > libfreetype.so.6 => /lib64/libfreetype.so.6 (0x00007fb58e204000) > libawt.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libawt.so (0x00007fb58df34000) > libjava.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libjava.so (0x00007fb58dd07000) > libjvm.so => not found > libawt_headless.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libawt_headless.so (0x00007fb58dafe000) > libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fb58d778000) > libm.so.6 => /lib64/libm.so.6 (0x00007fb58d423000) > libc.so.6 => /lib64/libc.so.6 (0x00007fb58d040000) > libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fb58ce29000) > libbz2.so.1 => /lib64/libbz2.so.1 (0x00007fb58cc18000) > libpng16.so.16 => /lib64/libpng16.so.16 (0x00007fb58c9e5000) > libz.so.1 => /lib64/libz.so.1 (0x00007fb58c7ce000) > libjvm.so => not found > libdl.so.2 => /lib64/libdl.so.2 (0x00007fb58c5ca000) > libjvm.so => not found > libverify.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libverify.so (0x00007fb58c3bb000) > /lib64/ld-linux-x86-64.so.2 (0x00007fb58e74f000) > libjvm.so => not found > libjvm.so => not found > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.02/ > > How does this look? > > Do I need an Oracle sponsor for this or can I push this to jdk/jdk > myself. > > Thanks, > Severin > > On Fri, 2018-01-26 at 09:44 -0800, Phil Race wrote: >> > I could not remove -lawt however. >> >> Ah yes, Erik sent me the errors and yes there are some 2D functions that are >> defined in libawt that fontmanager needs for text rendering support, so >> we can't remove that. >> >> libawt on these platforms with separate headless and xawt libraries >> could have >> more aptly be called lib2d .. since most of the true AWT functionality >> is in the xawt library. >> >> >> -phil. >> >> On 01/26/2018 09:23 AM, Erik Joelsson wrote: >>> This patch builds on Solaris: >>> >>> diff -r 50cd89fe209f make/lib/Awt2dLibraries.gmk >>> --- a/make/lib/Awt2dLibraries.gmk >>> +++ b/make/lib/Awt2dLibraries.gmk >>> @@ -683,15 +683,15 @@ >>> hidevf w_novirtualdescr arrowrtn2, \ >>> DISABLED_WARNINGS_microsoft := 4267 4244 4018 4090 4996 4146 4334 >>> 4819 4101, \ >>> MAPFILE := $(BUILD_LIBFONTMANAGER_MAPFILE), \ >>> - LDFLAGS := $(subst -Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB)) >>> $(LDFLAGS_CXX_JDK) \ >>> + LDFLAGS := $(LDFLAGS_JDKLIB) $(LDFLAGS_CXX_JDK) \ >>> $(call SET_SHARED_LIBRARY_ORIGIN), \ >>> LDFLAGS_unix := -L$(INSTALL_LIBRARIES_HERE), \ >>> LDFLAGS_macosx := -undefined dynamic_lookup, \ >>> LIBS := $(BUILD_LIBFONTMANAGER_FONTLIB), \ >>> LIBS_unix := -lawt -ljava -ljvm $(LIBM) $(LIBCXX), \ >>> - LIBS_linux := -lc, \ >>> + LIBS_linux := -lawt_headless -lc, \ >>> LIBS_solaris := -lawt_headless -lc, \ >>> LIBS_aix := -lawt_headless,\ >>> >>> I could not remove -lawt however. >>> >>> /Erik >>> >>> On 2018-01-26 09:15, Erik Joelsson wrote: >>>> On 2018-01-26 09:02, Severin Gehwolf wrote: >>>>> On Fri, 2018-01-26 at 08:54 -0800, Erik Joelsson wrote: >>>>>> On 2018-01-26 08:44, Phil Race wrote: >>>>>>> When this was fixed for Solaris >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8071710 >>>>>>> the observed problem was not building (although it could have been) >>>>>>> but at runtime. >>>>>>> I think you can verify what you've done with "ldd" .. >>>>>>> >>>>>>> This patch adds awt_headless.so, but does not remove awt.so. >>>>>>> >>>>>>> Perhaps the line >>>>>>> >>>>>>> LIBS_unix := -lawt -ljava -ljvm $(LIBM) $(LIBCXX) >>>>>>> After your fix I expect "ldd" should not need to show awt .. just >>>>>>> awt_headless >>>>>>> >>>>>>> ie linux should not have this -lawt dependency any more and the -lawt >>>>>>> dependency should be specific to windows + mac .. >>>>> Thanks for the review, Phil. I'll post an updated webrev shortly. >>>>> >>>>> Any thoughts on the LDFLAGS filtering? Shouldn't this only be done on >>>>> platforms that need it? solaris, linux, aix should already be fine >>>>> without filtering. >>>> I would say try removing the filtering. The affected flags are >>>> currently only set on linux and solaris. I will do a test build on >>>> the latter and see if the filtering is actually needed. >>>> >>>> /Erik >>>>> Thanks, >>>>> Severin >>>>> >>>>>> So we already use -lawt_headless on solaris and aix, then I really >>>>>> can't >>>>>> see a reason not to do the same for linux. >>>>>>> On 01/26/2018 08:10 AM, Severin Gehwolf wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Could I please get a review for this rather small patch which >>>>>>>> originally occurred for us on JDK 8 (Fedora) which recently >>>>>>>> switched to >>>>>>>> building with "-Wl,-z,defs" linker flags. The result was a build >>>>>>>> failure, due to unresolved symbols. Indeed libfontmanager.so should >>>>>>>> have -lawt_headless in the list of dependent libs as symbols such as >>>>>>>> AWTLoadFont come from libawt_headless.so, not libawt.so on Linux. >>>>>>>> Some >>>>>>>> more details are on the bug. >>>>>>>> >>>>>>>> webrev: >>>>>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.01/ >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196218 >>>>>>>> >>>>>>>> Testing: Build fails with configure option >>>>>>>> --with-extra-ldflags="-Xlinker -z -Xlinker defs" >>>>>>>> prior the fix. Succeeds after. >>>>>>>> >>>>>>>> Question for 2d-folks/build-dev folks: >>>>>>> I don't know about this, build folks probably know. >>>>>>> >>>>>> This is from way ahead of my time. The filtering is simply the >>>>>> build-infra way of achieving the same thing as in the old build >>>>>> system. >>>>>> Here is the corresponding code in jdk7: >>>>>> >>>>>> $ hg annotate make/sun/font/Makefile >>>>>> ... >>>>>> 0: # >>>>>> 0: # Created without -z defs on linux >>>>>> 0: # >>>>>> 0: ifeq ($(PLATFORM), linux) >>>>>> 0: LDFLAGS_DEFS_OPTION = >>>>>> 0: endif >>>>>> ... >>>>>> >>>>>> /Erik >>>>>> >>>>>>> -phil. >>>>>>>> There is this snippet in the libfontmanager block in >>>>>>>> make/lib/Awt2dLibraries.gmk, line 686: >>>>>>>> >>>>>>>> LDFLAGS := $(subst >>>>>>>> -Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB)) >>>>>>>> $(LDFLAGS_CXX_JDK) \ >>>>>>>> $(call SET_SHARED_LIBRARY_ORIGIN), \ >>>>>>>> >>>>>>>> It's my understanding that this is supposed to filter "-Wl,-z,defs" >>>>>>>> from LDFLAGS_JDKLIB. Does anybody know why it does so? Is there a >>>>>>>> legit >>>>>>>> reason when unresolved symbols at link time are OK? Besides, why >>>>>>>> does >>>>>>>> it not also filter "-Xlinker -z -Xlinker defs"? FWIW, in JDK 8 >>>>>>>> it's the >>>>>>>> other way round. Xlinker flags are filtered, but -Wl,-z,defs is not. >>>>>>>> Thoughts? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Severin >> From sgehwolf at redhat.com Mon Jan 29 16:50:50 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 29 Jan 2018 17:50:50 +0100 Subject: [OpenJDK 2D-Dev] RFR: JDK-8196218: [linux] libfontmanager should be linked against headless awt library In-Reply-To: <4657791d-45ff-deb6-b092-b3b28963dd4f@oracle.com> References: <1516983050.4518.21.camel@redhat.com> <6c63d26a-a056-99bd-c383-146784a4871c@oracle.com> <1516986142.4518.31.camel@redhat.com> <44fb0d96-b134-3fba-8ba8-bffa4fd2225f@oracle.com> <2d569244-42a1-c652-cf96-0761d22328bc@oracle.com> <1517218778.4106.10.camel@redhat.com> <4657791d-45ff-deb6-b092-b3b28963dd4f@oracle.com> Message-ID: <1517244650.4106.38.camel@redhat.com> On Mon, 2018-01-29 at 08:29 -0800, Erik Joelsson wrote: > This looks good to me. Good catch on the dependency declaration further > down. Yes, the build failed for me without that :) > I don't see any reason this would need a sponsor, jdk/jdk should > be open. Thanks for the review! I'll run this through the new submit repo and - barring unforeseen circumstances - will push it once approved. Cheers, Severin > On 2018-01-29 01:39, Severin Gehwolf wrote: > > Hi, > > > > Updated webrev which removes the linker flags filtering. Linking with > > the awt lib is being kept. ldd confirmed what Erik found out elsewhere: > > > > $ find build/linux-x86_64-normal-server-release/images/jdk -name libfontmanager.so > > build/linux-x86_64-normal-server-release/images/jdk/lib/libfontmanager.so > > $ ldd build/linux-x86_64-normal-server-release/images/jdk/lib/libfontmanager.so > > ldd: warning: you do not have execution permission for `build/linux-x86_64-normal-server-release/images/jdk/lib/libfontmanager.so' > > linux-vdso.so.1 (0x00007ffe13cc5000) > > libfreetype.so.6 => /lib64/libfreetype.so.6 (0x00007fb58e204000) > > libawt.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libawt.so (0x00007fb58df34000) > > libjava.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libjava.so (0x00007fb58dd07000) > > libjvm.so => not found > > libawt_headless.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libawt_headless.so (0x00007fb58dafe000) > > libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fb58d778000) > > libm.so.6 => /lib64/libm.so.6 (0x00007fb58d423000) > > libc.so.6 => /lib64/libc.so.6 (0x00007fb58d040000) > > libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fb58ce29000) > > libbz2.so.1 => /lib64/libbz2.so.1 (0x00007fb58cc18000) > > libpng16.so.16 => /lib64/libpng16.so.16 (0x00007fb58c9e5000) > > libz.so.1 => /lib64/libz.so.1 (0x00007fb58c7ce000) > > libjvm.so => not found > > libdl.so.2 => /lib64/libdl.so.2 (0x00007fb58c5ca000) > > libjvm.so => not found > > libverify.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libverify.so (0x00007fb58c3bb000) > > /lib64/ld-linux-x86-64.so.2 (0x00007fb58e74f000) > > libjvm.so => not found > > libjvm.so => not found > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.02/ > > > > How does this look? > > > > Do I need an Oracle sponsor for this or can I push this to jdk/jdk > > myself. > > > > Thanks, > > Severin > > > > On Fri, 2018-01-26 at 09:44 -0800, Phil Race wrote: > > > > I could not remove -lawt however. > > > > > > Ah yes, Erik sent me the errors and yes there are some 2D functions that are > > > defined in libawt that fontmanager needs for text rendering support, so > > > we can't remove that. > > > > > > libawt on these platforms with separate headless and xawt libraries > > > could have > > > more aptly be called lib2d .. since most of the true AWT functionality > > > is in the xawt library. > > > > > > > > > -phil. > > > > > > On 01/26/2018 09:23 AM, Erik Joelsson wrote: > > > > This patch builds on Solaris: > > > > > > > > diff -r 50cd89fe209f make/lib/Awt2dLibraries.gmk > > > > --- a/make/lib/Awt2dLibraries.gmk > > > > +++ b/make/lib/Awt2dLibraries.gmk > > > > @@ -683,15 +683,15 @@ > > > > hidevf w_novirtualdescr arrowrtn2, \ > > > > DISABLED_WARNINGS_microsoft := 4267 4244 4018 4090 4996 4146 4334 > > > > 4819 4101, \ > > > > MAPFILE := $(BUILD_LIBFONTMANAGER_MAPFILE), \ > > > > - LDFLAGS := $(subst -Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB)) > > > > $(LDFLAGS_CXX_JDK) \ > > > > + LDFLAGS := $(LDFLAGS_JDKLIB) $(LDFLAGS_CXX_JDK) \ > > > > $(call SET_SHARED_LIBRARY_ORIGIN), \ > > > > LDFLAGS_unix := -L$(INSTALL_LIBRARIES_HERE), \ > > > > LDFLAGS_macosx := -undefined dynamic_lookup, \ > > > > LIBS := $(BUILD_LIBFONTMANAGER_FONTLIB), \ > > > > LIBS_unix := -lawt -ljava -ljvm $(LIBM) $(LIBCXX), \ > > > > - LIBS_linux := -lc, \ > > > > + LIBS_linux := -lawt_headless -lc, \ > > > > LIBS_solaris := -lawt_headless -lc, \ > > > > LIBS_aix := -lawt_headless,\ > > > > > > > > I could not remove -lawt however. > > > > > > > > /Erik > > > > > > > > On 2018-01-26 09:15, Erik Joelsson wrote: > > > > > On 2018-01-26 09:02, Severin Gehwolf wrote: > > > > > > On Fri, 2018-01-26 at 08:54 -0800, Erik Joelsson wrote: > > > > > > > On 2018-01-26 08:44, Phil Race wrote: > > > > > > > > When this was fixed for Solaris > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8071710 > > > > > > > > the observed problem was not building (although it could have been) > > > > > > > > but at runtime. > > > > > > > > I think you can verify what you've done with "ldd" .. > > > > > > > > > > > > > > > > This patch adds awt_headless.so, but does not remove awt.so. > > > > > > > > > > > > > > > > Perhaps the line > > > > > > > > > > > > > > > > LIBS_unix := -lawt -ljava -ljvm $(LIBM) $(LIBCXX) > > > > > > > > After your fix I expect "ldd" should not need to show awt .. just > > > > > > > > awt_headless > > > > > > > > > > > > > > > > ie linux should not have this -lawt dependency any more and the -lawt > > > > > > > > dependency should be specific to windows + mac .. > > > > > > > > > > > > Thanks for the review, Phil. I'll post an updated webrev shortly. > > > > > > > > > > > > Any thoughts on the LDFLAGS filtering? Shouldn't this only be done on > > > > > > platforms that need it? solaris, linux, aix should already be fine > > > > > > without filtering. > > > > > > > > > > I would say try removing the filtering. The affected flags are > > > > > currently only set on linux and solaris. I will do a test build on > > > > > the latter and see if the filtering is actually needed. > > > > > > > > > > /Erik > > > > > > Thanks, > > > > > > Severin > > > > > > > > > > > > > So we already use -lawt_headless on solaris and aix, then I really > > > > > > > can't > > > > > > > see a reason not to do the same for linux. > > > > > > > > On 01/26/2018 08:10 AM, Severin Gehwolf wrote: > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > Could I please get a review for this rather small patch which > > > > > > > > > originally occurred for us on JDK 8 (Fedora) which recently > > > > > > > > > switched to > > > > > > > > > building with "-Wl,-z,defs" linker flags. The result was a build > > > > > > > > > failure, due to unresolved symbols. Indeed libfontmanager.so should > > > > > > > > > have -lawt_headless in the list of dependent libs as symbols such as > > > > > > > > > AWTLoadFont come from libawt_headless.so, not libawt.so on Linux. > > > > > > > > > Some > > > > > > > > > more details are on the bug. > > > > > > > > > > > > > > > > > > webrev: > > > > > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.01/ > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196218 > > > > > > > > > > > > > > > > > > Testing: Build fails with configure option > > > > > > > > > --with-extra-ldflags="-Xlinker -z -Xlinker defs" > > > > > > > > > prior the fix. Succeeds after. > > > > > > > > > > > > > > > > > > Question for 2d-folks/build-dev folks: > > > > > > > > > > > > > > > > I don't know about this, build folks probably know. > > > > > > > > > > > > > > > > > > > > > > This is from way ahead of my time. The filtering is simply the > > > > > > > build-infra way of achieving the same thing as in the old build > > > > > > > system. > > > > > > > Here is the corresponding code in jdk7: > > > > > > > > > > > > > > $ hg annotate make/sun/font/Makefile > > > > > > > ... > > > > > > > 0: # > > > > > > > 0: # Created without -z defs on linux > > > > > > > 0: # > > > > > > > 0: ifeq ($(PLATFORM), linux) > > > > > > > 0: LDFLAGS_DEFS_OPTION = > > > > > > > 0: endif > > > > > > > ... > > > > > > > > > > > > > > /Erik > > > > > > > > > > > > > > > -phil. > > > > > > > > > There is this snippet in the libfontmanager block in > > > > > > > > > make/lib/Awt2dLibraries.gmk, line 686: > > > > > > > > > > > > > > > > > > LDFLAGS := $(subst > > > > > > > > > -Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB)) > > > > > > > > > $(LDFLAGS_CXX_JDK) \ > > > > > > > > > $(call SET_SHARED_LIBRARY_ORIGIN), \ > > > > > > > > > > > > > > > > > > It's my understanding that this is supposed to filter "-Wl,-z,defs" > > > > > > > > > from LDFLAGS_JDKLIB. Does anybody know why it does so? Is there a > > > > > > > > > legit > > > > > > > > > reason when unresolved symbols at link time are OK? Besides, why > > > > > > > > > does > > > > > > > > > it not also filter "-Xlinker -z -Xlinker defs"? FWIW, in JDK 8 > > > > > > > > > it's the > > > > > > > > > other way round. Xlinker flags are filtered, but -Wl,-z,defs is not. > > > > > > > > > Thoughts? > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > Severin > > From sgehwolf at redhat.com Mon Jan 29 18:53:51 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 29 Jan 2018 19:53:51 +0100 Subject: [OpenJDK 2D-Dev] RFR: JDK-8196218: [linux] libfontmanager should be linked against headless awt library In-Reply-To: <4657791d-45ff-deb6-b092-b3b28963dd4f@oracle.com> References: <1516983050.4518.21.camel@redhat.com> <6c63d26a-a056-99bd-c383-146784a4871c@oracle.com> <1516986142.4518.31.camel@redhat.com> <44fb0d96-b134-3fba-8ba8-bffa4fd2225f@oracle.com> <2d569244-42a1-c652-cf96-0761d22328bc@oracle.com> <1517218778.4106.10.camel@redhat.com> <4657791d-45ff-deb6-b092-b3b28963dd4f@oracle.com> Message-ID: <1517252031.4106.47.camel@redhat.com> Hi Phil, Are you OK with the latest webrev as well? http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.02/ Thanks, Severin On Mon, 2018-01-29 at 08:29 -0800, Erik Joelsson wrote: > This looks good to me. Good catch on the dependency declaration further > down. I don't see any reason this would need a sponsor, jdk/jdk should > be open. > > /Erik > > > On 2018-01-29 01:39, Severin Gehwolf wrote: > > Hi, > > > > Updated webrev which removes the linker flags filtering. Linking with > > the awt lib is being kept. ldd confirmed what Erik found out elsewhere: > > > > $ find build/linux-x86_64-normal-server-release/images/jdk -name libfontmanager.so > > build/linux-x86_64-normal-server-release/images/jdk/lib/libfontmanager.so > > $ ldd build/linux-x86_64-normal-server-release/images/jdk/lib/libfontmanager.so > > ldd: warning: you do not have execution permission for `build/linux-x86_64-normal-server-release/images/jdk/lib/libfontmanager.so' > > linux-vdso.so.1 (0x00007ffe13cc5000) > > libfreetype.so.6 => /lib64/libfreetype.so.6 (0x00007fb58e204000) > > libawt.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libawt.so (0x00007fb58df34000) > > libjava.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libjava.so (0x00007fb58dd07000) > > libjvm.so => not found > > libawt_headless.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libawt_headless.so (0x00007fb58dafe000) > > libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fb58d778000) > > libm.so.6 => /lib64/libm.so.6 (0x00007fb58d423000) > > libc.so.6 => /lib64/libc.so.6 (0x00007fb58d040000) > > libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fb58ce29000) > > libbz2.so.1 => /lib64/libbz2.so.1 (0x00007fb58cc18000) > > libpng16.so.16 => /lib64/libpng16.so.16 (0x00007fb58c9e5000) > > libz.so.1 => /lib64/libz.so.1 (0x00007fb58c7ce000) > > libjvm.so => not found > > libdl.so.2 => /lib64/libdl.so.2 (0x00007fb58c5ca000) > > libjvm.so => not found > > libverify.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libverify.so (0x00007fb58c3bb000) > > /lib64/ld-linux-x86-64.so.2 (0x00007fb58e74f000) > > libjvm.so => not found > > libjvm.so => not found > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.02/ > > > > How does this look? > > > > Do I need an Oracle sponsor for this or can I push this to jdk/jdk > > myself. > > > > Thanks, > > Severin > > > > On Fri, 2018-01-26 at 09:44 -0800, Phil Race wrote: > > > > I could not remove -lawt however. > > > > > > Ah yes, Erik sent me the errors and yes there are some 2D functions that are > > > defined in libawt that fontmanager needs for text rendering support, so > > > we can't remove that. > > > > > > libawt on these platforms with separate headless and xawt libraries > > > could have > > > more aptly be called lib2d .. since most of the true AWT functionality > > > is in the xawt library. > > > > > > > > > -phil. > > > > > > On 01/26/2018 09:23 AM, Erik Joelsson wrote: > > > > This patch builds on Solaris: > > > > > > > > diff -r 50cd89fe209f make/lib/Awt2dLibraries.gmk > > > > --- a/make/lib/Awt2dLibraries.gmk > > > > +++ b/make/lib/Awt2dLibraries.gmk > > > > @@ -683,15 +683,15 @@ > > > > hidevf w_novirtualdescr arrowrtn2, \ > > > > DISABLED_WARNINGS_microsoft := 4267 4244 4018 4090 4996 4146 4334 > > > > 4819 4101, \ > > > > MAPFILE := $(BUILD_LIBFONTMANAGER_MAPFILE), \ > > > > - LDFLAGS := $(subst -Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB)) > > > > $(LDFLAGS_CXX_JDK) \ > > > > + LDFLAGS := $(LDFLAGS_JDKLIB) $(LDFLAGS_CXX_JDK) \ > > > > $(call SET_SHARED_LIBRARY_ORIGIN), \ > > > > LDFLAGS_unix := -L$(INSTALL_LIBRARIES_HERE), \ > > > > LDFLAGS_macosx := -undefined dynamic_lookup, \ > > > > LIBS := $(BUILD_LIBFONTMANAGER_FONTLIB), \ > > > > LIBS_unix := -lawt -ljava -ljvm $(LIBM) $(LIBCXX), \ > > > > - LIBS_linux := -lc, \ > > > > + LIBS_linux := -lawt_headless -lc, \ > > > > LIBS_solaris := -lawt_headless -lc, \ > > > > LIBS_aix := -lawt_headless,\ > > > > > > > > I could not remove -lawt however. > > > > > > > > /Erik > > > > > > > > On 2018-01-26 09:15, Erik Joelsson wrote: > > > > > On 2018-01-26 09:02, Severin Gehwolf wrote: > > > > > > On Fri, 2018-01-26 at 08:54 -0800, Erik Joelsson wrote: > > > > > > > On 2018-01-26 08:44, Phil Race wrote: > > > > > > > > When this was fixed for Solaris > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8071710 > > > > > > > > the observed problem was not building (although it could have been) > > > > > > > > but at runtime. > > > > > > > > I think you can verify what you've done with "ldd" .. > > > > > > > > > > > > > > > > This patch adds awt_headless.so, but does not remove awt.so. > > > > > > > > > > > > > > > > Perhaps the line > > > > > > > > > > > > > > > > LIBS_unix := -lawt -ljava -ljvm $(LIBM) $(LIBCXX) > > > > > > > > After your fix I expect "ldd" should not need to show awt .. just > > > > > > > > awt_headless > > > > > > > > > > > > > > > > ie linux should not have this -lawt dependency any more and the -lawt > > > > > > > > dependency should be specific to windows + mac .. > > > > > > > > > > > > Thanks for the review, Phil. I'll post an updated webrev shortly. > > > > > > > > > > > > Any thoughts on the LDFLAGS filtering? Shouldn't this only be done on > > > > > > platforms that need it? solaris, linux, aix should already be fine > > > > > > without filtering. > > > > > > > > > > I would say try removing the filtering. The affected flags are > > > > > currently only set on linux and solaris. I will do a test build on > > > > > the latter and see if the filtering is actually needed. > > > > > > > > > > /Erik > > > > > > Thanks, > > > > > > Severin > > > > > > > > > > > > > So we already use -lawt_headless on solaris and aix, then I really > > > > > > > can't > > > > > > > see a reason not to do the same for linux. > > > > > > > > On 01/26/2018 08:10 AM, Severin Gehwolf wrote: > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > Could I please get a review for this rather small patch which > > > > > > > > > originally occurred for us on JDK 8 (Fedora) which recently > > > > > > > > > switched to > > > > > > > > > building with "-Wl,-z,defs" linker flags. The result was a build > > > > > > > > > failure, due to unresolved symbols. Indeed libfontmanager.so should > > > > > > > > > have -lawt_headless in the list of dependent libs as symbols such as > > > > > > > > > AWTLoadFont come from libawt_headless.so, not libawt.so on Linux. > > > > > > > > > Some > > > > > > > > > more details are on the bug. > > > > > > > > > > > > > > > > > > webrev: > > > > > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.01/ > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196218 > > > > > > > > > > > > > > > > > > Testing: Build fails with configure option > > > > > > > > > --with-extra-ldflags="-Xlinker -z -Xlinker defs" > > > > > > > > > prior the fix. Succeeds after. > > > > > > > > > > > > > > > > > > Question for 2d-folks/build-dev folks: > > > > > > > > > > > > > > > > I don't know about this, build folks probably know. > > > > > > > > > > > > > > > > > > > > > > This is from way ahead of my time. The filtering is simply the > > > > > > > build-infra way of achieving the same thing as in the old build > > > > > > > system. > > > > > > > Here is the corresponding code in jdk7: > > > > > > > > > > > > > > $ hg annotate make/sun/font/Makefile > > > > > > > ... > > > > > > > 0: # > > > > > > > 0: # Created without -z defs on linux > > > > > > > 0: # > > > > > > > 0: ifeq ($(PLATFORM), linux) > > > > > > > 0: LDFLAGS_DEFS_OPTION = > > > > > > > 0: endif > > > > > > > ... > > > > > > > > > > > > > > /Erik > > > > > > > > > > > > > > > -phil. > > > > > > > > > There is this snippet in the libfontmanager block in > > > > > > > > > make/lib/Awt2dLibraries.gmk, line 686: > > > > > > > > > > > > > > > > > > LDFLAGS := $(subst > > > > > > > > > -Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB)) > > > > > > > > > $(LDFLAGS_CXX_JDK) \ > > > > > > > > > $(call SET_SHARED_LIBRARY_ORIGIN), \ > > > > > > > > > > > > > > > > > > It's my understanding that this is supposed to filter "-Wl,-z,defs" > > > > > > > > > from LDFLAGS_JDKLIB. Does anybody know why it does so? Is there a > > > > > > > > > legit > > > > > > > > > reason when unresolved symbols at link time are OK? Besides, why > > > > > > > > > does > > > > > > > > > it not also filter "-Xlinker -z -Xlinker defs"? FWIW, in JDK 8 > > > > > > > > > it's the > > > > > > > > > other way round. Xlinker flags are filtered, but -Wl,-z,defs is not. > > > > > > > > > Thoughts? > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > Severin > > From philip.race at oracle.com Mon Jan 29 20:09:35 2018 From: philip.race at oracle.com (Phil Race) Date: Mon, 29 Jan 2018 12:09:35 -0800 Subject: [OpenJDK 2D-Dev] RFR: JDK-8196218: [linux] libfontmanager should be linked against headless awt library In-Reply-To: <1517252031.4106.47.camel@redhat.com> References: <1516983050.4518.21.camel@redhat.com> <6c63d26a-a056-99bd-c383-146784a4871c@oracle.com> <1516986142.4518.31.camel@redhat.com> <44fb0d96-b134-3fba-8ba8-bffa4fd2225f@oracle.com> <2d569244-42a1-c652-cf96-0761d22328bc@oracle.com> <1517218778.4106.10.camel@redhat.com> <4657791d-45ff-deb6-b092-b3b28963dd4f@oracle.com> <1517252031.4106.47.camel@redhat.com> Message-ID: <2479e9ec-18db-02fe-01bd-69ae29862173@oracle.com> It looks OK but have you tried running it through the new build system discussed here ? http://mail.openjdk.java.net/pipermail/jdk-dev/2018-January/000566.html -phil. On 01/29/2018 10:53 AM, Severin Gehwolf wrote: > Hi Phil, > > Are you OK with the latest webrev as well? > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.02/ > > Thanks, > Severin > > On Mon, 2018-01-29 at 08:29 -0800, Erik Joelsson wrote: >> This looks good to me. Good catch on the dependency declaration further >> down. I don't see any reason this would need a sponsor, jdk/jdk should >> be open. >> >> /Erik >> >> >> On 2018-01-29 01:39, Severin Gehwolf wrote: >>> Hi, >>> >>> Updated webrev which removes the linker flags filtering. Linking with >>> the awt lib is being kept. ldd confirmed what Erik found out elsewhere: >>> >>> $ find build/linux-x86_64-normal-server-release/images/jdk -name libfontmanager.so >>> build/linux-x86_64-normal-server-release/images/jdk/lib/libfontmanager.so >>> $ ldd build/linux-x86_64-normal-server-release/images/jdk/lib/libfontmanager.so >>> ldd: warning: you do not have execution permission for `build/linux-x86_64-normal-server-release/images/jdk/lib/libfontmanager.so' >>> linux-vdso.so.1 (0x00007ffe13cc5000) >>> libfreetype.so.6 => /lib64/libfreetype.so.6 (0x00007fb58e204000) >>> libawt.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libawt.so (0x00007fb58df34000) >>> libjava.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libjava.so (0x00007fb58dd07000) >>> libjvm.so => not found >>> libawt_headless.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libawt_headless.so (0x00007fb58dafe000) >>> libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fb58d778000) >>> libm.so.6 => /lib64/libm.so.6 (0x00007fb58d423000) >>> libc.so.6 => /lib64/libc.so.6 (0x00007fb58d040000) >>> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fb58ce29000) >>> libbz2.so.1 => /lib64/libbz2.so.1 (0x00007fb58cc18000) >>> libpng16.so.16 => /lib64/libpng16.so.16 (0x00007fb58c9e5000) >>> libz.so.1 => /lib64/libz.so.1 (0x00007fb58c7ce000) >>> libjvm.so => not found >>> libdl.so.2 => /lib64/libdl.so.2 (0x00007fb58c5ca000) >>> libjvm.so => not found >>> libverify.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libverify.so (0x00007fb58c3bb000) >>> /lib64/ld-linux-x86-64.so.2 (0x00007fb58e74f000) >>> libjvm.so => not found >>> libjvm.so => not found >>> >>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.02/ >>> >>> How does this look? >>> >>> Do I need an Oracle sponsor for this or can I push this to jdk/jdk >>> myself. >>> >>> Thanks, >>> Severin >>> >>> On Fri, 2018-01-26 at 09:44 -0800, Phil Race wrote: >>>> > I could not remove -lawt however. >>>> >>>> Ah yes, Erik sent me the errors and yes there are some 2D functions that are >>>> defined in libawt that fontmanager needs for text rendering support, so >>>> we can't remove that. >>>> >>>> libawt on these platforms with separate headless and xawt libraries >>>> could have >>>> more aptly be called lib2d .. since most of the true AWT functionality >>>> is in the xawt library. >>>> >>>> >>>> -phil. >>>> >>>> On 01/26/2018 09:23 AM, Erik Joelsson wrote: >>>>> This patch builds on Solaris: >>>>> >>>>> diff -r 50cd89fe209f make/lib/Awt2dLibraries.gmk >>>>> --- a/make/lib/Awt2dLibraries.gmk >>>>> +++ b/make/lib/Awt2dLibraries.gmk >>>>> @@ -683,15 +683,15 @@ >>>>> hidevf w_novirtualdescr arrowrtn2, \ >>>>> DISABLED_WARNINGS_microsoft := 4267 4244 4018 4090 4996 4146 4334 >>>>> 4819 4101, \ >>>>> MAPFILE := $(BUILD_LIBFONTMANAGER_MAPFILE), \ >>>>> - LDFLAGS := $(subst -Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB)) >>>>> $(LDFLAGS_CXX_JDK) \ >>>>> + LDFLAGS := $(LDFLAGS_JDKLIB) $(LDFLAGS_CXX_JDK) \ >>>>> $(call SET_SHARED_LIBRARY_ORIGIN), \ >>>>> LDFLAGS_unix := -L$(INSTALL_LIBRARIES_HERE), \ >>>>> LDFLAGS_macosx := -undefined dynamic_lookup, \ >>>>> LIBS := $(BUILD_LIBFONTMANAGER_FONTLIB), \ >>>>> LIBS_unix := -lawt -ljava -ljvm $(LIBM) $(LIBCXX), \ >>>>> - LIBS_linux := -lc, \ >>>>> + LIBS_linux := -lawt_headless -lc, \ >>>>> LIBS_solaris := -lawt_headless -lc, \ >>>>> LIBS_aix := -lawt_headless,\ >>>>> >>>>> I could not remove -lawt however. >>>>> >>>>> /Erik >>>>> >>>>> On 2018-01-26 09:15, Erik Joelsson wrote: >>>>>> On 2018-01-26 09:02, Severin Gehwolf wrote: >>>>>>> On Fri, 2018-01-26 at 08:54 -0800, Erik Joelsson wrote: >>>>>>>> On 2018-01-26 08:44, Phil Race wrote: >>>>>>>>> When this was fixed for Solaris >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8071710 >>>>>>>>> the observed problem was not building (although it could have been) >>>>>>>>> but at runtime. >>>>>>>>> I think you can verify what you've done with "ldd" .. >>>>>>>>> >>>>>>>>> This patch adds awt_headless.so, but does not remove awt.so. >>>>>>>>> >>>>>>>>> Perhaps the line >>>>>>>>> >>>>>>>>> LIBS_unix := -lawt -ljava -ljvm $(LIBM) $(LIBCXX) >>>>>>>>> After your fix I expect "ldd" should not need to show awt .. just >>>>>>>>> awt_headless >>>>>>>>> >>>>>>>>> ie linux should not have this -lawt dependency any more and the -lawt >>>>>>>>> dependency should be specific to windows + mac .. >>>>>>> Thanks for the review, Phil. I'll post an updated webrev shortly. >>>>>>> >>>>>>> Any thoughts on the LDFLAGS filtering? Shouldn't this only be done on >>>>>>> platforms that need it? solaris, linux, aix should already be fine >>>>>>> without filtering. >>>>>> I would say try removing the filtering. The affected flags are >>>>>> currently only set on linux and solaris. I will do a test build on >>>>>> the latter and see if the filtering is actually needed. >>>>>> >>>>>> /Erik >>>>>>> Thanks, >>>>>>> Severin >>>>>>> >>>>>>>> So we already use -lawt_headless on solaris and aix, then I really >>>>>>>> can't >>>>>>>> see a reason not to do the same for linux. >>>>>>>>> On 01/26/2018 08:10 AM, Severin Gehwolf wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Could I please get a review for this rather small patch which >>>>>>>>>> originally occurred for us on JDK 8 (Fedora) which recently >>>>>>>>>> switched to >>>>>>>>>> building with "-Wl,-z,defs" linker flags. The result was a build >>>>>>>>>> failure, due to unresolved symbols. Indeed libfontmanager.so should >>>>>>>>>> have -lawt_headless in the list of dependent libs as symbols such as >>>>>>>>>> AWTLoadFont come from libawt_headless.so, not libawt.so on Linux. >>>>>>>>>> Some >>>>>>>>>> more details are on the bug. >>>>>>>>>> >>>>>>>>>> webrev: >>>>>>>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.01/ >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196218 >>>>>>>>>> >>>>>>>>>> Testing: Build fails with configure option >>>>>>>>>> --with-extra-ldflags="-Xlinker -z -Xlinker defs" >>>>>>>>>> prior the fix. Succeeds after. >>>>>>>>>> >>>>>>>>>> Question for 2d-folks/build-dev folks: >>>>>>>>> I don't know about this, build folks probably know. >>>>>>>>> >>>>>>>> This is from way ahead of my time. The filtering is simply the >>>>>>>> build-infra way of achieving the same thing as in the old build >>>>>>>> system. >>>>>>>> Here is the corresponding code in jdk7: >>>>>>>> >>>>>>>> $ hg annotate make/sun/font/Makefile >>>>>>>> ... >>>>>>>> 0: # >>>>>>>> 0: # Created without -z defs on linux >>>>>>>> 0: # >>>>>>>> 0: ifeq ($(PLATFORM), linux) >>>>>>>> 0: LDFLAGS_DEFS_OPTION = >>>>>>>> 0: endif >>>>>>>> ... >>>>>>>> >>>>>>>> /Erik >>>>>>>> >>>>>>>>> -phil. >>>>>>>>>> There is this snippet in the libfontmanager block in >>>>>>>>>> make/lib/Awt2dLibraries.gmk, line 686: >>>>>>>>>> >>>>>>>>>> LDFLAGS := $(subst >>>>>>>>>> -Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB)) >>>>>>>>>> $(LDFLAGS_CXX_JDK) \ >>>>>>>>>> $(call SET_SHARED_LIBRARY_ORIGIN), \ >>>>>>>>>> >>>>>>>>>> It's my understanding that this is supposed to filter "-Wl,-z,defs" >>>>>>>>>> from LDFLAGS_JDKLIB. Does anybody know why it does so? Is there a >>>>>>>>>> legit >>>>>>>>>> reason when unresolved symbols at link time are OK? Besides, why >>>>>>>>>> does >>>>>>>>>> it not also filter "-Xlinker -z -Xlinker defs"? FWIW, in JDK 8 >>>>>>>>>> it's the >>>>>>>>>> other way round. Xlinker flags are filtered, but -Wl,-z,defs is not. >>>>>>>>>> Thoughts? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Severin >> From sgehwolf at redhat.com Tue Jan 30 08:42:28 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 30 Jan 2018 09:42:28 +0100 Subject: [OpenJDK 2D-Dev] RFR: JDK-8196218: [linux] libfontmanager should be linked against headless awt library In-Reply-To: <2479e9ec-18db-02fe-01bd-69ae29862173@oracle.com> References: <1516983050.4518.21.camel@redhat.com> <6c63d26a-a056-99bd-c383-146784a4871c@oracle.com> <1516986142.4518.31.camel@redhat.com> <44fb0d96-b134-3fba-8ba8-bffa4fd2225f@oracle.com> <2d569244-42a1-c652-cf96-0761d22328bc@oracle.com> <1517218778.4106.10.camel@redhat.com> <4657791d-45ff-deb6-b092-b3b28963dd4f@oracle.com> <1517252031.4106.47.camel@redhat.com> <2479e9ec-18db-02fe-01bd-69ae29862173@oracle.com> Message-ID: <1517301748.4159.1.camel@redhat.com> On Mon, 2018-01-29 at 12:09 -0800, Phil Race wrote: > It looks OK but have you tried running it through the new build system > discussed here ? > http://mail.openjdk.java.net/pipermail/jdk-dev/2018-January/000566.html Thanks. I've submitted it yesterday, yes. No response - via email - so far, though. Cheers, Severin > -phil. > > On 01/29/2018 10:53 AM, Severin Gehwolf wrote: > > Hi Phil, > > > > Are you OK with the latest webrev as well? > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.02/ > > > > Thanks, > > Severin > > > > On Mon, 2018-01-29 at 08:29 -0800, Erik Joelsson wrote: > > > This looks good to me. Good catch on the dependency declaration further > > > down. I don't see any reason this would need a sponsor, jdk/jdk should > > > be open. > > > > > > /Erik > > > > > > > > > On 2018-01-29 01:39, Severin Gehwolf wrote: > > > > Hi, > > > > > > > > Updated webrev which removes the linker flags filtering. Linking with > > > > the awt lib is being kept. ldd confirmed what Erik found out elsewhere: > > > > > > > > $ find build/linux-x86_64-normal-server-release/images/jdk -name libfontmanager.so > > > > build/linux-x86_64-normal-server-release/images/jdk/lib/libfontmanager.so > > > > $ ldd build/linux-x86_64-normal-server-release/images/jdk/lib/libfontmanager.so > > > > ldd: warning: you do not have execution permission for `build/linux-x86_64-normal-server-release/images/jdk/lib/libfontmanager.so' > > > > linux-vdso.so.1 (0x00007ffe13cc5000) > > > > libfreetype.so.6 => /lib64/libfreetype.so.6 (0x00007fb58e204000) > > > > libawt.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libawt.so (0x00007fb58df34000) > > > > libjava.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libjava.so (0x00007fb58dd07000) > > > > libjvm.so => not found > > > > libawt_headless.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libawt_headless.so (0x00007fb58dafe000) > > > > libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fb58d778000) > > > > libm.so.6 => /lib64/libm.so.6 (0x00007fb58d423000) > > > > libc.so.6 => /lib64/libc.so.6 (0x00007fb58d040000) > > > > libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fb58ce29000) > > > > libbz2.so.1 => /lib64/libbz2.so.1 (0x00007fb58cc18000) > > > > libpng16.so.16 => /lib64/libpng16.so.16 (0x00007fb58c9e5000) > > > > libz.so.1 => /lib64/libz.so.1 (0x00007fb58c7ce000) > > > > libjvm.so => not found > > > > libdl.so.2 => /lib64/libdl.so.2 (0x00007fb58c5ca000) > > > > libjvm.so => not found > > > > libverify.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libverify.so (0x00007fb58c3bb000) > > > > /lib64/ld-linux-x86-64.so.2 (0x00007fb58e74f000) > > > > libjvm.so => not found > > > > libjvm.so => not found > > > > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.02/ > > > > > > > > How does this look? > > > > > > > > Do I need an Oracle sponsor for this or can I push this to jdk/jdk > > > > myself. > > > > > > > > Thanks, > > > > Severin > > > > > > > > On Fri, 2018-01-26 at 09:44 -0800, Phil Race wrote: > > > > > > I could not remove -lawt however. > > > > > > > > > > Ah yes, Erik sent me the errors and yes there are some 2D functions that are > > > > > defined in libawt that fontmanager needs for text rendering support, so > > > > > we can't remove that. > > > > > > > > > > libawt on these platforms with separate headless and xawt libraries > > > > > could have > > > > > more aptly be called lib2d .. since most of the true AWT functionality > > > > > is in the xawt library. > > > > > > > > > > > > > > > -phil. > > > > > > > > > > On 01/26/2018 09:23 AM, Erik Joelsson wrote: > > > > > > This patch builds on Solaris: > > > > > > > > > > > > diff -r 50cd89fe209f make/lib/Awt2dLibraries.gmk > > > > > > --- a/make/lib/Awt2dLibraries.gmk > > > > > > +++ b/make/lib/Awt2dLibraries.gmk > > > > > > @@ -683,15 +683,15 @@ > > > > > > hidevf w_novirtualdescr arrowrtn2, \ > > > > > > DISABLED_WARNINGS_microsoft := 4267 4244 4018 4090 4996 4146 4334 > > > > > > 4819 4101, \ > > > > > > MAPFILE := $(BUILD_LIBFONTMANAGER_MAPFILE), \ > > > > > > - LDFLAGS := $(subst -Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB)) > > > > > > $(LDFLAGS_CXX_JDK) \ > > > > > > + LDFLAGS := $(LDFLAGS_JDKLIB) $(LDFLAGS_CXX_JDK) \ > > > > > > $(call SET_SHARED_LIBRARY_ORIGIN), \ > > > > > > LDFLAGS_unix := -L$(INSTALL_LIBRARIES_HERE), \ > > > > > > LDFLAGS_macosx := -undefined dynamic_lookup, \ > > > > > > LIBS := $(BUILD_LIBFONTMANAGER_FONTLIB), \ > > > > > > LIBS_unix := -lawt -ljava -ljvm $(LIBM) $(LIBCXX), \ > > > > > > - LIBS_linux := -lc, \ > > > > > > + LIBS_linux := -lawt_headless -lc, \ > > > > > > LIBS_solaris := -lawt_headless -lc, \ > > > > > > LIBS_aix := -lawt_headless,\ > > > > > > > > > > > > I could not remove -lawt however. > > > > > > > > > > > > /Erik > > > > > > > > > > > > On 2018-01-26 09:15, Erik Joelsson wrote: > > > > > > > On 2018-01-26 09:02, Severin Gehwolf wrote: > > > > > > > > On Fri, 2018-01-26 at 08:54 -0800, Erik Joelsson wrote: > > > > > > > > > On 2018-01-26 08:44, Phil Race wrote: > > > > > > > > > > When this was fixed for Solaris > > > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8071710 > > > > > > > > > > the observed problem was not building (although it could have been) > > > > > > > > > > but at runtime. > > > > > > > > > > I think you can verify what you've done with "ldd" .. > > > > > > > > > > > > > > > > > > > > This patch adds awt_headless.so, but does not remove awt.so. > > > > > > > > > > > > > > > > > > > > Perhaps the line > > > > > > > > > > > > > > > > > > > > LIBS_unix := -lawt -ljava -ljvm $(LIBM) $(LIBCXX) > > > > > > > > > > After your fix I expect "ldd" should not need to show awt .. just > > > > > > > > > > awt_headless > > > > > > > > > > > > > > > > > > > > ie linux should not have this -lawt dependency any more and the -lawt > > > > > > > > > > dependency should be specific to windows + mac .. > > > > > > > > > > > > > > > > Thanks for the review, Phil. I'll post an updated webrev shortly. > > > > > > > > > > > > > > > > Any thoughts on the LDFLAGS filtering? Shouldn't this only be done on > > > > > > > > platforms that need it? solaris, linux, aix should already be fine > > > > > > > > without filtering. > > > > > > > > > > > > > > I would say try removing the filtering. The affected flags are > > > > > > > currently only set on linux and solaris. I will do a test build on > > > > > > > the latter and see if the filtering is actually needed. > > > > > > > > > > > > > > /Erik > > > > > > > > Thanks, > > > > > > > > Severin > > > > > > > > > > > > > > > > > So we already use -lawt_headless on solaris and aix, then I really > > > > > > > > > can't > > > > > > > > > see a reason not to do the same for linux. > > > > > > > > > > On 01/26/2018 08:10 AM, Severin Gehwolf wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > Could I please get a review for this rather small patch which > > > > > > > > > > > originally occurred for us on JDK 8 (Fedora) which recently > > > > > > > > > > > switched to > > > > > > > > > > > building with "-Wl,-z,defs" linker flags. The result was a build > > > > > > > > > > > failure, due to unresolved symbols. Indeed libfontmanager.so should > > > > > > > > > > > have -lawt_headless in the list of dependent libs as symbols such as > > > > > > > > > > > AWTLoadFont come from libawt_headless.so, not libawt.so on Linux. > > > > > > > > > > > Some > > > > > > > > > > > more details are on the bug. > > > > > > > > > > > > > > > > > > > > > > webrev: > > > > > > > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.01/ > > > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196218 > > > > > > > > > > > > > > > > > > > > > > Testing: Build fails with configure option > > > > > > > > > > > --with-extra-ldflags="-Xlinker -z -Xlinker defs" > > > > > > > > > > > prior the fix. Succeeds after. > > > > > > > > > > > > > > > > > > > > > > Question for 2d-folks/build-dev folks: > > > > > > > > > > > > > > > > > > > > I don't know about this, build folks probably know. > > > > > > > > > > > > > > > > > > > > > > > > > > > > This is from way ahead of my time. The filtering is simply the > > > > > > > > > build-infra way of achieving the same thing as in the old build > > > > > > > > > system. > > > > > > > > > Here is the corresponding code in jdk7: > > > > > > > > > > > > > > > > > > $ hg annotate make/sun/font/Makefile > > > > > > > > > ... > > > > > > > > > 0: # > > > > > > > > > 0: # Created without -z defs on linux > > > > > > > > > 0: # > > > > > > > > > 0: ifeq ($(PLATFORM), linux) > > > > > > > > > 0: LDFLAGS_DEFS_OPTION = > > > > > > > > > 0: endif > > > > > > > > > ... > > > > > > > > > > > > > > > > > > /Erik > > > > > > > > > > > > > > > > > > > -phil. > > > > > > > > > > > There is this snippet in the libfontmanager block in > > > > > > > > > > > make/lib/Awt2dLibraries.gmk, line 686: > > > > > > > > > > > > > > > > > > > > > > LDFLAGS := $(subst > > > > > > > > > > > -Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB)) > > > > > > > > > > > $(LDFLAGS_CXX_JDK) \ > > > > > > > > > > > $(call SET_SHARED_LIBRARY_ORIGIN), \ > > > > > > > > > > > > > > > > > > > > > > It's my understanding that this is supposed to filter "-Wl,-z,defs" > > > > > > > > > > > from LDFLAGS_JDKLIB. Does anybody know why it does so? Is there a > > > > > > > > > > > legit > > > > > > > > > > > reason when unresolved symbols at link time are OK? Besides, why > > > > > > > > > > > does > > > > > > > > > > > it not also filter "-Xlinker -z -Xlinker defs"? FWIW, in JDK 8 > > > > > > > > > > > it's the > > > > > > > > > > > other way round. Xlinker flags are filtered, but -Wl,-z,defs is not. > > > > > > > > > > > Thoughts? > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > Severin > > From erik.joelsson at oracle.com Tue Jan 30 16:36:38 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 30 Jan 2018 08:36:38 -0800 (PST) Subject: [OpenJDK 2D-Dev] RFR: JDK-8196218: [linux] libfontmanager should be linked against headless awt library In-Reply-To: <1517301748.4159.1.camel@redhat.com> References: <1516983050.4518.21.camel@redhat.com> <6c63d26a-a056-99bd-c383-146784a4871c@oracle.com> <1516986142.4518.31.camel@redhat.com> <44fb0d96-b134-3fba-8ba8-bffa4fd2225f@oracle.com> <2d569244-42a1-c652-cf96-0761d22328bc@oracle.com> <1517218778.4106.10.camel@redhat.com> <4657791d-45ff-deb6-b092-b3b28963dd4f@oracle.com> <1517252031.4106.47.camel@redhat.com> <2479e9ec-18db-02fe-01bd-69ae29862173@oracle.com> <1517301748.4159.1.camel@redhat.com> Message-ID: <87a8ef58-4c83-42e2-59be-db23be9f4343@oracle.com> I found your job and it's all successful. Something is up with the service though. I'm pinging the relevant people here. /Erik On 2018-01-30 00:42, Severin Gehwolf wrote: > On Mon, 2018-01-29 at 12:09 -0800, Phil Race wrote: >> It looks OK but have you tried running it through the new build system >> discussed here ? >> http://mail.openjdk.java.net/pipermail/jdk-dev/2018-January/000566.html > Thanks. I've submitted it yesterday, yes. No response - via email - so > far, though. > > Cheers, > Severin > >> -phil. >> >> On 01/29/2018 10:53 AM, Severin Gehwolf wrote: >>> Hi Phil, >>> >>> Are you OK with the latest webrev as well? >>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.02/ >>> >>> Thanks, >>> Severin >>> >>> On Mon, 2018-01-29 at 08:29 -0800, Erik Joelsson wrote: >>>> This looks good to me. Good catch on the dependency declaration further >>>> down. I don't see any reason this would need a sponsor, jdk/jdk should >>>> be open. >>>> >>>> /Erik >>>> >>>> >>>> On 2018-01-29 01:39, Severin Gehwolf wrote: >>>>> Hi, >>>>> >>>>> Updated webrev which removes the linker flags filtering. Linking with >>>>> the awt lib is being kept. ldd confirmed what Erik found out elsewhere: >>>>> >>>>> $ find build/linux-x86_64-normal-server-release/images/jdk -name libfontmanager.so >>>>> build/linux-x86_64-normal-server-release/images/jdk/lib/libfontmanager.so >>>>> $ ldd build/linux-x86_64-normal-server-release/images/jdk/lib/libfontmanager.so >>>>> ldd: warning: you do not have execution permission for `build/linux-x86_64-normal-server-release/images/jdk/lib/libfontmanager.so' >>>>> linux-vdso.so.1 (0x00007ffe13cc5000) >>>>> libfreetype.so.6 => /lib64/libfreetype.so.6 (0x00007fb58e204000) >>>>> libawt.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libawt.so (0x00007fb58df34000) >>>>> libjava.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libjava.so (0x00007fb58dd07000) >>>>> libjvm.so => not found >>>>> libawt_headless.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libawt_headless.so (0x00007fb58dafe000) >>>>> libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fb58d778000) >>>>> libm.so.6 => /lib64/libm.so.6 (0x00007fb58d423000) >>>>> libc.so.6 => /lib64/libc.so.6 (0x00007fb58d040000) >>>>> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fb58ce29000) >>>>> libbz2.so.1 => /lib64/libbz2.so.1 (0x00007fb58cc18000) >>>>> libpng16.so.16 => /lib64/libpng16.so.16 (0x00007fb58c9e5000) >>>>> libz.so.1 => /lib64/libz.so.1 (0x00007fb58c7ce000) >>>>> libjvm.so => not found >>>>> libdl.so.2 => /lib64/libdl.so.2 (0x00007fb58c5ca000) >>>>> libjvm.so => not found >>>>> libverify.so => /disk/openjdk/upstream-sources/openjdk-hs/build/linux-x86_64-normal-server-release/images/jdk/lib/libverify.so (0x00007fb58c3bb000) >>>>> /lib64/ld-linux-x86-64.so.2 (0x00007fb58e74f000) >>>>> libjvm.so => not found >>>>> libjvm.so => not found >>>>> >>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.02/ >>>>> >>>>> How does this look? >>>>> >>>>> Do I need an Oracle sponsor for this or can I push this to jdk/jdk >>>>> myself. >>>>> >>>>> Thanks, >>>>> Severin >>>>> >>>>> On Fri, 2018-01-26 at 09:44 -0800, Phil Race wrote: >>>>>> > I could not remove -lawt however. >>>>>> >>>>>> Ah yes, Erik sent me the errors and yes there are some 2D functions that are >>>>>> defined in libawt that fontmanager needs for text rendering support, so >>>>>> we can't remove that. >>>>>> >>>>>> libawt on these platforms with separate headless and xawt libraries >>>>>> could have >>>>>> more aptly be called lib2d .. since most of the true AWT functionality >>>>>> is in the xawt library. >>>>>> >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 01/26/2018 09:23 AM, Erik Joelsson wrote: >>>>>>> This patch builds on Solaris: >>>>>>> >>>>>>> diff -r 50cd89fe209f make/lib/Awt2dLibraries.gmk >>>>>>> --- a/make/lib/Awt2dLibraries.gmk >>>>>>> +++ b/make/lib/Awt2dLibraries.gmk >>>>>>> @@ -683,15 +683,15 @@ >>>>>>> hidevf w_novirtualdescr arrowrtn2, \ >>>>>>> DISABLED_WARNINGS_microsoft := 4267 4244 4018 4090 4996 4146 4334 >>>>>>> 4819 4101, \ >>>>>>> MAPFILE := $(BUILD_LIBFONTMANAGER_MAPFILE), \ >>>>>>> - LDFLAGS := $(subst -Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB)) >>>>>>> $(LDFLAGS_CXX_JDK) \ >>>>>>> + LDFLAGS := $(LDFLAGS_JDKLIB) $(LDFLAGS_CXX_JDK) \ >>>>>>> $(call SET_SHARED_LIBRARY_ORIGIN), \ >>>>>>> LDFLAGS_unix := -L$(INSTALL_LIBRARIES_HERE), \ >>>>>>> LDFLAGS_macosx := -undefined dynamic_lookup, \ >>>>>>> LIBS := $(BUILD_LIBFONTMANAGER_FONTLIB), \ >>>>>>> LIBS_unix := -lawt -ljava -ljvm $(LIBM) $(LIBCXX), \ >>>>>>> - LIBS_linux := -lc, \ >>>>>>> + LIBS_linux := -lawt_headless -lc, \ >>>>>>> LIBS_solaris := -lawt_headless -lc, \ >>>>>>> LIBS_aix := -lawt_headless,\ >>>>>>> >>>>>>> I could not remove -lawt however. >>>>>>> >>>>>>> /Erik >>>>>>> >>>>>>> On 2018-01-26 09:15, Erik Joelsson wrote: >>>>>>>> On 2018-01-26 09:02, Severin Gehwolf wrote: >>>>>>>>> On Fri, 2018-01-26 at 08:54 -0800, Erik Joelsson wrote: >>>>>>>>>> On 2018-01-26 08:44, Phil Race wrote: >>>>>>>>>>> When this was fixed for Solaris >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8071710 >>>>>>>>>>> the observed problem was not building (although it could have been) >>>>>>>>>>> but at runtime. >>>>>>>>>>> I think you can verify what you've done with "ldd" .. >>>>>>>>>>> >>>>>>>>>>> This patch adds awt_headless.so, but does not remove awt.so. >>>>>>>>>>> >>>>>>>>>>> Perhaps the line >>>>>>>>>>> >>>>>>>>>>> LIBS_unix := -lawt -ljava -ljvm $(LIBM) $(LIBCXX) >>>>>>>>>>> After your fix I expect "ldd" should not need to show awt .. just >>>>>>>>>>> awt_headless >>>>>>>>>>> >>>>>>>>>>> ie linux should not have this -lawt dependency any more and the -lawt >>>>>>>>>>> dependency should be specific to windows + mac .. >>>>>>>>> Thanks for the review, Phil. I'll post an updated webrev shortly. >>>>>>>>> >>>>>>>>> Any thoughts on the LDFLAGS filtering? Shouldn't this only be done on >>>>>>>>> platforms that need it? solaris, linux, aix should already be fine >>>>>>>>> without filtering. >>>>>>>> I would say try removing the filtering. The affected flags are >>>>>>>> currently only set on linux and solaris. I will do a test build on >>>>>>>> the latter and see if the filtering is actually needed. >>>>>>>> >>>>>>>> /Erik >>>>>>>>> Thanks, >>>>>>>>> Severin >>>>>>>>> >>>>>>>>>> So we already use -lawt_headless on solaris and aix, then I really >>>>>>>>>> can't >>>>>>>>>> see a reason not to do the same for linux. >>>>>>>>>>> On 01/26/2018 08:10 AM, Severin Gehwolf wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> Could I please get a review for this rather small patch which >>>>>>>>>>>> originally occurred for us on JDK 8 (Fedora) which recently >>>>>>>>>>>> switched to >>>>>>>>>>>> building with "-Wl,-z,defs" linker flags. The result was a build >>>>>>>>>>>> failure, due to unresolved symbols. Indeed libfontmanager.so should >>>>>>>>>>>> have -lawt_headless in the list of dependent libs as symbols such as >>>>>>>>>>>> AWTLoadFont come from libawt_headless.so, not libawt.so on Linux. >>>>>>>>>>>> Some >>>>>>>>>>>> more details are on the bug. >>>>>>>>>>>> >>>>>>>>>>>> webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev.01/ >>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196218 >>>>>>>>>>>> >>>>>>>>>>>> Testing: Build fails with configure option >>>>>>>>>>>> --with-extra-ldflags="-Xlinker -z -Xlinker defs" >>>>>>>>>>>> prior the fix. Succeeds after. >>>>>>>>>>>> >>>>>>>>>>>> Question for 2d-folks/build-dev folks: >>>>>>>>>>> I don't know about this, build folks probably know. >>>>>>>>>>> >>>>>>>>>> This is from way ahead of my time. The filtering is simply the >>>>>>>>>> build-infra way of achieving the same thing as in the old build >>>>>>>>>> system. >>>>>>>>>> Here is the corresponding code in jdk7: >>>>>>>>>> >>>>>>>>>> $ hg annotate make/sun/font/Makefile >>>>>>>>>> ... >>>>>>>>>> 0: # >>>>>>>>>> 0: # Created without -z defs on linux >>>>>>>>>> 0: # >>>>>>>>>> 0: ifeq ($(PLATFORM), linux) >>>>>>>>>> 0: LDFLAGS_DEFS_OPTION = >>>>>>>>>> 0: endif >>>>>>>>>> ... >>>>>>>>>> >>>>>>>>>> /Erik >>>>>>>>>> >>>>>>>>>>> -phil. >>>>>>>>>>>> There is this snippet in the libfontmanager block in >>>>>>>>>>>> make/lib/Awt2dLibraries.gmk, line 686: >>>>>>>>>>>> >>>>>>>>>>>> LDFLAGS := $(subst >>>>>>>>>>>> -Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB)) >>>>>>>>>>>> $(LDFLAGS_CXX_JDK) \ >>>>>>>>>>>> $(call SET_SHARED_LIBRARY_ORIGIN), \ >>>>>>>>>>>> >>>>>>>>>>>> It's my understanding that this is supposed to filter "-Wl,-z,defs" >>>>>>>>>>>> from LDFLAGS_JDKLIB. Does anybody know why it does so? Is there a >>>>>>>>>>>> legit >>>>>>>>>>>> reason when unresolved symbols at link time are OK? Besides, why >>>>>>>>>>>> does >>>>>>>>>>>> it not also filter "-Xlinker -z -Xlinker defs"? FWIW, in JDK 8 >>>>>>>>>>>> it's the >>>>>>>>>>>> other way round. Xlinker flags are filtered, but -Wl,-z,defs is not. >>>>>>>>>>>> Thoughts? >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Severin >> From sgehwolf at redhat.com Tue Jan 30 16:49:27 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 30 Jan 2018 17:49:27 +0100 Subject: [OpenJDK 2D-Dev] RFR: JDK-8196218: [linux] libfontmanager should be linked against headless awt library In-Reply-To: <87a8ef58-4c83-42e2-59be-db23be9f4343@oracle.com> References: <1516983050.4518.21.camel@redhat.com> <6c63d26a-a056-99bd-c383-146784a4871c@oracle.com> <1516986142.4518.31.camel@redhat.com> <44fb0d96-b134-3fba-8ba8-bffa4fd2225f@oracle.com> <2d569244-42a1-c652-cf96-0761d22328bc@oracle.com> <1517218778.4106.10.camel@redhat.com> <4657791d-45ff-deb6-b092-b3b28963dd4f@oracle.com> <1517252031.4106.47.camel@redhat.com> <2479e9ec-18db-02fe-01bd-69ae29862173@oracle.com> <1517301748.4159.1.camel@redhat.com> <87a8ef58-4c83-42e2-59be-db23be9f4343@oracle.com> Message-ID: <1517330967.4159.36.camel@redhat.com> On Tue, 2018-01-30 at 08:36 -0800, Erik Joelsson wrote: > I found your job and it's all successful. Something is up with the > service though. I'm pinging the relevant people here. Yes, indeed: http://mail.openjdk.java.net/pipermail/jdk-dev/2018-January/000622.html Thanks, Erik! Cheers, Severin From sgehwolf at redhat.com Tue Jan 30 17:05:19 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 30 Jan 2018 18:05:19 +0100 Subject: [OpenJDK 2D-Dev] RFR: JDK-8196218: [linux] libfontmanager should be linked against headless awt library In-Reply-To: <87a8ef58-4c83-42e2-59be-db23be9f4343@oracle.com> References: <1516983050.4518.21.camel@redhat.com> <6c63d26a-a056-99bd-c383-146784a4871c@oracle.com> <1516986142.4518.31.camel@redhat.com> <44fb0d96-b134-3fba-8ba8-bffa4fd2225f@oracle.com> <2d569244-42a1-c652-cf96-0761d22328bc@oracle.com> <1517218778.4106.10.camel@redhat.com> <4657791d-45ff-deb6-b092-b3b28963dd4f@oracle.com> <1517252031.4106.47.camel@redhat.com> <2479e9ec-18db-02fe-01bd-69ae29862173@oracle.com> <1517301748.4159.1.camel@redhat.com> <87a8ef58-4c83-42e2-59be-db23be9f4343@oracle.com> Message-ID: <1517331919.4159.39.camel@redhat.com> On Tue, 2018-01-30 at 08:36 -0800, Erik Joelsson wrote: > I found your job and it's all successful. Something is up with the > service though. I'm pinging the relevant people here. Phil, Erik: Where should I push this to? jdk or client? http://hg.openjdk.java.net/jdk/client/ or http://hg.openjdk.java.net/jdk/jdk/ Thanks, Severin > /Erik > > > On 2018-01-30 00:42, Severin Gehwolf wrote: > > On Mon, 2018-01-29 at 12:09 -0800, Phil Race wrote: > > > It looks OK but have you tried running it through the new build > > > system > > > discussed here ? > > > http://mail.openjdk.java.net/pipermail/jdk-dev/2018-January/00056 > > > 6.html > > > > Thanks. I've submitted it yesterday, yes. No response - via email - > > so > > far, though. > > > > Cheers, > > Severin > > > > > -phil. > > > > > > On 01/29/2018 10:53 AM, Severin Gehwolf wrote: > > > > Hi Phil, > > > > > > > > Are you OK with the latest webrev as well? > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/webrev > > > > .02/ > > > > > > > > Thanks, > > > > Severin > > > > > > > > On Mon, 2018-01-29 at 08:29 -0800, Erik Joelsson wrote: > > > > > This looks good to me. Good catch on the dependency > > > > > declaration further > > > > > down. I don't see any reason this would need a sponsor, > > > > > jdk/jdk should > > > > > be open. > > > > > > > > > > /Erik > > > > > > > > > > > > > > > On 2018-01-29 01:39, Severin Gehwolf wrote: > > > > > > Hi, > > > > > > > > > > > > Updated webrev which removes the linker flags filtering. > > > > > > Linking with > > > > > > the awt lib is being kept. ldd confirmed what Erik found > > > > > > out elsewhere: > > > > > > > > > > > > $ find build/linux-x86_64-normal-server-release/images/jdk > > > > > > -name libfontmanager.so > > > > > > build/linux-x86_64-normal-server- > > > > > > release/images/jdk/lib/libfontmanager.so > > > > > > $ ldd build/linux-x86_64-normal-server- > > > > > > release/images/jdk/lib/libfontmanager.so > > > > > > ldd: warning: you do not have execution permission for > > > > > > `build/linux-x86_64-normal-server- > > > > > > release/images/jdk/lib/libfontmanager.so' > > > > > > linux-vdso.so.1 (0x00007ffe13cc5000) > > > > > > libfreetype.so.6 => /lib64/libfreetype.so.6 > > > > > > (0x00007fb58e204000) > > > > > > libawt.so => /disk/openjdk/upstream-sources/openjdk- > > > > > > hs/build/linux-x86_64-normal-server- > > > > > > release/images/jdk/lib/libawt.so (0x00007fb58df34000) > > > > > > libjava.so => /disk/openjdk/upstream-sources/openjdk- > > > > > > hs/build/linux-x86_64-normal-server- > > > > > > release/images/jdk/lib/libjava.so (0x00007fb58dd07000) > > > > > > libjvm.so => not found > > > > > > libawt_headless.so => /disk/openjdk/upstream- > > > > > > sources/openjdk-hs/build/linux-x86_64-normal-server- > > > > > > release/images/jdk/lib/libawt_headless.so > > > > > > (0x00007fb58dafe000) > > > > > > libstdc++.so.6 => /lib64/libstdc++.so.6 > > > > > > (0x00007fb58d778000) > > > > > > libm.so.6 => /lib64/libm.so.6 (0x00007fb58d423000) > > > > > > libc.so.6 => /lib64/libc.so.6 (0x00007fb58d040000) > > > > > > libgcc_s.so.1 => /lib64/libgcc_s.so.1 > > > > > > (0x00007fb58ce29000) > > > > > > libbz2.so.1 => /lib64/libbz2.so.1 (0x00007fb58cc18000) > > > > > > libpng16.so.16 => /lib64/libpng16.so.16 > > > > > > (0x00007fb58c9e5000) > > > > > > libz.so.1 => /lib64/libz.so.1 (0x00007fb58c7ce000) > > > > > > libjvm.so => not found > > > > > > libdl.so.2 => /lib64/libdl.so.2 (0x00007fb58c5ca000) > > > > > > libjvm.so => not found > > > > > > libverify.so => /disk/openjdk/upstream-sources/openjdk- > > > > > > hs/build/linux-x86_64-normal-server- > > > > > > release/images/jdk/lib/libverify.so (0x00007fb58c3bb000) > > > > > > /lib64/ld-linux-x86-64.so.2 (0x00007fb58e74f000) > > > > > > libjvm.so => not found > > > > > > libjvm.so => not found > > > > > > > > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196218/we > > > > > > brev.02/ > > > > > > > > > > > > How does this look? > > > > > > > > > > > > Do I need an Oracle sponsor for this or can I push this to > > > > > > jdk/jdk > > > > > > myself. > > > > > > > > > > > > Thanks, > > > > > > Severin > > > > > > > > > > > > On Fri, 2018-01-26 at 09:44 -0800, Phil Race wrote: > > > > > > > > I could not remove -lawt however. > > > > > > > > > > > > > > Ah yes, Erik sent me the errors and yes there are some 2D > > > > > > > functions that are > > > > > > > defined in libawt that fontmanager needs for text > > > > > > > rendering support, so > > > > > > > we can't remove that. > > > > > > > > > > > > > > libawt on these platforms with separate headless and xawt > > > > > > > libraries > > > > > > > could have > > > > > > > more aptly be called lib2d .. since most of the true AWT > > > > > > > functionality > > > > > > > is in the xawt library. > > > > > > > > > > > > > > > > > > > > > -phil. > > > > > > > > > > > > > > On 01/26/2018 09:23 AM, Erik Joelsson wrote: > > > > > > > > This patch builds on Solaris: > > > > > > > > > > > > > > > > diff -r 50cd89fe209f make/lib/Awt2dLibraries.gmk > > > > > > > > --- a/make/lib/Awt2dLibraries.gmk > > > > > > > > +++ b/make/lib/Awt2dLibraries.gmk > > > > > > > > @@ -683,15 +683,15 @@ > > > > > > > > hidevf w_novirtualdescr arrowrtn2, \ > > > > > > > > DISABLED_WARNINGS_microsoft := 4267 4244 4018 > > > > > > > > 4090 4996 4146 4334 > > > > > > > > 4819 4101, \ > > > > > > > > MAPFILE := $(BUILD_LIBFONTMANAGER_MAPFILE), \ > > > > > > > > - LDFLAGS := $(subst -Wl$(COMMA)- > > > > > > > > z$(COMMA)defs,,$(LDFLAGS_JDKLIB)) > > > > > > > > $(LDFLAGS_CXX_JDK) \ > > > > > > > > + LDFLAGS := $(LDFLAGS_JDKLIB) $(LDFLAGS_CXX_JDK) \ > > > > > > > > $(call SET_SHARED_LIBRARY_ORIGIN), \ > > > > > > > > LDFLAGS_unix := -L$(INSTALL_LIBRARIES_HERE), \ > > > > > > > > LDFLAGS_macosx := -undefined dynamic_lookup, \ > > > > > > > > LIBS := $(BUILD_LIBFONTMANAGER_FONTLIB), \ > > > > > > > > LIBS_unix := -lawt -ljava -ljvm $(LIBM) > > > > > > > > $(LIBCXX), \ > > > > > > > > - LIBS_linux := -lc, \ > > > > > > > > + LIBS_linux := -lawt_headless -lc, \ > > > > > > > > LIBS_solaris := -lawt_headless -lc, \ > > > > > > > > LIBS_aix := -lawt_headless,\ > > > > > > > > > > > > > > > > I could not remove -lawt however. > > > > > > > > > > > > > > > > /Erik > > > > > > > > > > > > > > > > On 2018-01-26 09:15, Erik Joelsson wrote: > > > > > > > > > On 2018-01-26 09:02, Severin Gehwolf wrote: > > > > > > > > > > On Fri, 2018-01-26 at 08:54 -0800, Erik Joelsson > > > > > > > > > > wrote: > > > > > > > > > > > On 2018-01-26 08:44, Phil Race wrote: > > > > > > > > > > > > When this was fixed for Solaris > > > > > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-807171 > > > > > > > > > > > > 0 > > > > > > > > > > > > the observed problem was not building (although > > > > > > > > > > > > it could have been) > > > > > > > > > > > > but at runtime. > > > > > > > > > > > > I think you can verify what you've done with > > > > > > > > > > > > "ldd" .. > > > > > > > > > > > > > > > > > > > > > > > > This patch adds awt_headless.so, but does not > > > > > > > > > > > > remove awt.so. > > > > > > > > > > > > > > > > > > > > > > > > Perhaps the line > > > > > > > > > > > > > > > > > > > > > > > > LIBS_unix := -lawt -ljava -ljvm $(LIBM) > > > > > > > > > > > > $(LIBCXX) > > > > > > > > > > > > After your fix I expect "ldd" should not need > > > > > > > > > > > > to show awt .. just > > > > > > > > > > > > awt_headless > > > > > > > > > > > > > > > > > > > > > > > > ie linux should not have this -lawt dependency > > > > > > > > > > > > any more and the -lawt > > > > > > > > > > > > dependency should be specific to windows + mac > > > > > > > > > > > > .. > > > > > > > > > > > > > > > > > > > > Thanks for the review, Phil. I'll post an updated > > > > > > > > > > webrev shortly. > > > > > > > > > > > > > > > > > > > > Any thoughts on the LDFLAGS filtering? Shouldn't > > > > > > > > > > this only be done on > > > > > > > > > > platforms that need it? solaris, linux, aix should > > > > > > > > > > already be fine > > > > > > > > > > without filtering. > > > > > > > > > > > > > > > > > > I would say try removing the filtering. The affected > > > > > > > > > flags are > > > > > > > > > currently only set on linux and solaris. I will do a > > > > > > > > > test build on > > > > > > > > > the latter and see if the filtering is actually > > > > > > > > > needed. > > > > > > > > > > > > > > > > > > /Erik > > > > > > > > > > Thanks, > > > > > > > > > > Severin > > > > > > > > > > > > > > > > > > > > > So we already use -lawt_headless on solaris and > > > > > > > > > > > aix, then I really > > > > > > > > > > > can't > > > > > > > > > > > see a reason not to do the same for linux. > > > > > > > > > > > > On 01/26/2018 08:10 AM, Severin Gehwolf wrote: > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > > > Could I please get a review for this rather > > > > > > > > > > > > > small patch which > > > > > > > > > > > > > originally occurred for us on JDK 8 (Fedora) > > > > > > > > > > > > > which recently > > > > > > > > > > > > > switched to > > > > > > > > > > > > > building with "-Wl,-z,defs" linker flags. The > > > > > > > > > > > > > result was a build > > > > > > > > > > > > > failure, due to unresolved symbols. Indeed > > > > > > > > > > > > > libfontmanager.so should > > > > > > > > > > > > > have -lawt_headless in the list of dependent > > > > > > > > > > > > > libs as symbols such as > > > > > > > > > > > > > AWTLoadFont come from libawt_headless.so, not > > > > > > > > > > > > > libawt.so on Linux. > > > > > > > > > > > > > Some > > > > > > > > > > > > > more details are on the bug. > > > > > > > > > > > > > > > > > > > > > > > > > > webrev: > > > > > > > > > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/ > > > > > > > > > > > > > JDK-8196218/webrev.01/ > > > > > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK > > > > > > > > > > > > > -8196218 > > > > > > > > > > > > > > > > > > > > > > > > > > Testing: Build fails with configure option > > > > > > > > > > > > > --with-extra-ldflags="-Xlinker > > > > > > > > > > > > > -z -Xlinker defs" > > > > > > > > > > > > > prior the fix. Succeeds after. > > > > > > > > > > > > > > > > > > > > > > > > > > Question for 2d-folks/build-dev folks: > > > > > > > > > > > > > > > > > > > > > > > > I don't know about this, build folks probably > > > > > > > > > > > > know. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This is from way ahead of my time. The filtering > > > > > > > > > > > is simply the > > > > > > > > > > > build-infra way of achieving the same thing as in > > > > > > > > > > > the old build > > > > > > > > > > > system. > > > > > > > > > > > Here is the corresponding code in jdk7: > > > > > > > > > > > > > > > > > > > > > > $ hg annotate make/sun/font/Makefile > > > > > > > > > > > ... > > > > > > > > > > > 0: # > > > > > > > > > > > 0: # Created without -z defs on linux > > > > > > > > > > > 0: # > > > > > > > > > > > 0: ifeq ($(PLATFORM), linux) > > > > > > > > > > > 0: LDFLAGS_DEFS_OPTION = > > > > > > > > > > > 0: endif > > > > > > > > > > > ... > > > > > > > > > > > > > > > > > > > > > > /Erik > > > > > > > > > > > > > > > > > > > > > > > -phil. > > > > > > > > > > > > > There is this snippet in the libfontmanager > > > > > > > > > > > > > block in > > > > > > > > > > > > > make/lib/Awt2dLibraries.gmk, line 686: > > > > > > > > > > > > > > > > > > > > > > > > > > LDFLAGS := $(subst > > > > > > > > > > > > > -Wl$(COMMA)-z$(COMMA)defs,,$(LDFLAGS_JDKLIB)) > > > > > > > > > > > > > $(LDFLAGS_CXX_JDK) \ > > > > > > > > > > > > > $(call > > > > > > > > > > > > > SET_SHARED_LIBRARY_ORIGIN), \ > > > > > > > > > > > > > > > > > > > > > > > > > > It's my understanding that this is supposed > > > > > > > > > > > > > to filter "-Wl,-z,defs" > > > > > > > > > > > > > from LDFLAGS_JDKLIB. Does anybody know why it > > > > > > > > > > > > > does so? Is there a > > > > > > > > > > > > > legit > > > > > > > > > > > > > reason when unresolved symbols at link time > > > > > > > > > > > > > are OK? Besides, why > > > > > > > > > > > > > does > > > > > > > > > > > > > it not also filter "-Xlinker -z -Xlinker > > > > > > > > > > > > > defs"? FWIW, in JDK 8 > > > > > > > > > > > > > it's the > > > > > > > > > > > > > other way round. Xlinker flags are filtered, > > > > > > > > > > > > > but -Wl,-z,defs is not. > > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > Severin > > From philip.race at oracle.com Tue Jan 30 17:16:33 2018 From: philip.race at oracle.com (Phil Race) Date: Tue, 30 Jan 2018 09:16:33 -0800 Subject: [OpenJDK 2D-Dev] RFR: JDK-8196218: [linux] libfontmanager should be linked against headless awt library In-Reply-To: <1517331919.4159.39.camel@redhat.com> References: <1516983050.4518.21.camel@redhat.com> <6c63d26a-a056-99bd-c383-146784a4871c@oracle.com> <1516986142.4518.31.camel@redhat.com> <44fb0d96-b134-3fba-8ba8-bffa4fd2225f@oracle.com> <2d569244-42a1-c652-cf96-0761d22328bc@oracle.com> <1517218778.4106.10.camel@redhat.com> <4657791d-45ff-deb6-b092-b3b28963dd4f@oracle.com> <1517252031.4106.47.camel@redhat.com> <2479e9ec-18db-02fe-01bd-69ae29862173@oracle.com> <1517301748.4159.1.camel@redhat.com> <87a8ef58-4c83-42e2-59be-db23be9f4343@oracle.com> <1517331919.4159.39.camel@redhat.com> Message-ID: On 1/30/2018 9:05 AM, Severin Gehwolf wrote: > On Tue, 2018-01-30 at 08:36 -0800, Erik Joelsson wrote: >> I found your job and it's all successful. Something is up with the >> service though. I'm pinging the relevant people here. > Phil, Erik: Where should I push this to? jdk or client? A good question. Since it has passed builds on all platforms, then we know that is fine, but if you push to jdk/jdk there may not be any actual testing of the effects of the change before inclusion in a promotion. So you can push to jdk/jdk but it is a calculated risk .. if it were me I'd push to jdk/client. -phil. > > http://hg.openjdk.java.net/jdk/client/ > > or > > http://hg.openjdk.java.net/jdk/jdk/ > > Thanks, > Severin From philip.race at oracle.com Wed Jan 31 00:07:56 2018 From: philip.race at oracle.com (Phil Race) Date: Tue, 30 Jan 2018 16:07:56 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8196468 : Client jtreg ProblemList updates Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8196468 Webrev: http://cr.openjdk.java.net/~prr/8196468/ There's some noise in here as I moved the swing tests added last time to be listed next to other swing tests and grouped a few other tests together. The biggest additions are a lot of failures on linux that are filed as just a few bugs since they are likely the same underlying issue - probably a product /platform issue and some tests that jtreg says have errors. Most of the Windows additions here are tests that timeout for a variety of reasons. -phil. From Sergey.Bylokhov at oracle.com Wed Jan 31 02:30:03 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 30 Jan 2018 18:30:03 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8196468 : Client jtreg ProblemList updates In-Reply-To: References: Message-ID: <6aeb4573-5c65-1585-5ab0-e35c7034032e@oracle.com> Looks fine. On 30/01/2018 16:07, Phil Race wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8196468 > Webrev: http://cr.openjdk.java.net/~prr/8196468/ > > There's some noise in here as I moved the swing tests added last time to > be listed > next to other swing tests and grouped a few other tests together. > > The biggest additions are a lot of failures on linux that are filed as > just a few bugs > since they are likely the same underlying issue - probably a product > /platform issue > and some tests that jtreg says have errors. > > Most of the Windows additions here are tests that timeout for a variety > of reasons. > > -phil. > -- Best regards, Sergey. From philip.race at oracle.com Wed Jan 31 16:49:43 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 31 Jan 2018 08:49:43 -0800 Subject: [OpenJDK 2D-Dev] RFR: JDK-8196218: [linux] libfontmanager should be linked against headless awt library In-Reply-To: References: <1516983050.4518.21.camel@redhat.com> <6c63d26a-a056-99bd-c383-146784a4871c@oracle.com> <1516986142.4518.31.camel@redhat.com> <44fb0d96-b134-3fba-8ba8-bffa4fd2225f@oracle.com> <2d569244-42a1-c652-cf96-0761d22328bc@oracle.com> <1517218778.4106.10.camel@redhat.com> <4657791d-45ff-deb6-b092-b3b28963dd4f@oracle.com> <1517252031.4106.47.camel@redhat.com> <2479e9ec-18db-02fe-01bd-69ae29862173@oracle.com> <1517301748.4159.1.camel@redhat.com> <87a8ef58-4c83-42e2-59be-db23be9f4343@oracle.com> <1517331919.4159.39.camel@redhat.com> Message-ID: <0caee810-84f0-e3eb-5e32-a331e2be4473@oracle.com> Severin, Did you run any UI apps on a full (make all) build with the final version of the patch applied ? It appears to have completely broken all UI apps on Linux and about 800 UI tests failed last night. Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException: native ops missing at java.desktop/sun.java2d.xr.XRSurfaceData.freeXSDOPicture(Native Method) An exploded build is fine but the images build (what we ship) is broken. I think I'll need to back this out. A good thing it was pushed to client .. -phil. On 01/30/2018 09:16 AM, Phil Race wrote: > On 1/30/2018 9:05 AM, Severin Gehwolf wrote: >> On Tue, 2018-01-30 at 08:36 -0800, Erik Joelsson wrote: >>> I found your job and it's all successful. Something is up with the >>> service though. I'm pinging the relevant people here. >> Phil, Erik: Where should I push this to? jdk or client? > > A good question. Since it has passed builds on all platforms, then we > know that is fine, > but if you push to jdk/jdk there may not be any actual testing of the > effects of the change before > inclusion in a promotion. > > So you can push to jdk/jdk but it is a calculated risk .. if it were > me I'd push to jdk/client. > > -phil. > >> >> http://hg.openjdk.java.net/jdk/client/ >> >> or >> >> http://hg.openjdk.java.net/jdk/jdk/ >> >> Thanks, >> Severin > From philip.race at oracle.com Wed Jan 31 16:53:49 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 31 Jan 2018 08:53:49 -0800 Subject: [OpenJDK 2D-Dev] RFR: JDK-8196218: [linux] libfontmanager should be linked against headless awt library In-Reply-To: <0caee810-84f0-e3eb-5e32-a331e2be4473@oracle.com> References: <1516983050.4518.21.camel@redhat.com> <6c63d26a-a056-99bd-c383-146784a4871c@oracle.com> <1516986142.4518.31.camel@redhat.com> <44fb0d96-b134-3fba-8ba8-bffa4fd2225f@oracle.com> <2d569244-42a1-c652-cf96-0761d22328bc@oracle.com> <1517218778.4106.10.camel@redhat.com> <4657791d-45ff-deb6-b092-b3b28963dd4f@oracle.com> <1517252031.4106.47.camel@redhat.com> <2479e9ec-18db-02fe-01bd-69ae29862173@oracle.com> <1517301748.4159.1.camel@redhat.com> <87a8ef58-4c83-42e2-59be-db23be9f4343@oracle.com> <1517331919.4159.39.camel@redhat.com> <0caee810-84f0-e3eb-5e32-a331e2be4473@oracle.com> Message-ID: <22db6c1f-42b5-f36a-b0a3-c6ee84d8f896@oracle.com> Reverting the change it out seems to cure the problem. I've filed https://bugs.openjdk.java.net/browse/JDK-8196509 -phil. On 01/31/2018 08:49 AM, Phil Race wrote: > Severin, > > Did you run any UI apps on a full (make all) build with the final > version of the patch applied ? > It appears to have completely broken all UI apps on Linux and about > 800 UI tests failed last night. > Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException: > native ops missing > at java.desktop/sun.java2d.xr.XRSurfaceData.freeXSDOPicture(Native > Method) > > An exploded build is fine but the images build (what we ship) is broken. > > I think I'll need to back this out. > > A good thing it was pushed to client .. > > -phil. > > On 01/30/2018 09:16 AM, Phil Race wrote: >> On 1/30/2018 9:05 AM, Severin Gehwolf wrote: >>> On Tue, 2018-01-30 at 08:36 -0800, Erik Joelsson wrote: >>>> I found your job and it's all successful. Something is up with the >>>> service though. I'm pinging the relevant people here. >>> Phil, Erik: Where should I push this to? jdk or client? >> >> A good question. Since it has passed builds on all platforms, then we >> know that is fine, >> but if you push to jdk/jdk there may not be any actual testing of the >> effects of the change before >> inclusion in a promotion. >> >> So you can push to jdk/jdk but it is a calculated risk .. if it were >> me I'd push to jdk/client. >> >> -phil. >> >>> >>> http://hg.openjdk.java.net/jdk/client/ >>> >>> or >>> >>> http://hg.openjdk.java.net/jdk/jdk/ >>> >>> Thanks, >>> Severin >> > From philip.race at oracle.com Wed Jan 31 17:11:11 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 31 Jan 2018 09:11:11 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8196509: Linux UI applications broken by the build change for JDK-8196218 In-Reply-To: References: Message-ID: <4f13cf57-0bd9-768c-c3a8-6e0931bb79b6@oracle.com> Adding build-dev and 2d-dev. -phil. On 01/31/2018 09:10 AM, Phil Race wrote: > All UI apps are broken on Linux : > > Bug : https://bugs.openjdk.java.net/browse/JDK-8196509 > Webrev: http://cr.openjdk.java.net/~prr/8196509/ > > The fix (for now) is a straightforward reversion of the change here : > http://hg.openjdk.java.net/jdk/client/rev/2f4fe7776a53 > > -phil From erik.joelsson at oracle.com Wed Jan 31 17:28:59 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 31 Jan 2018 09:28:59 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8196509: Linux UI applications broken by the build change for JDK-8196218 In-Reply-To: <4f13cf57-0bd9-768c-c3a8-6e0931bb79b6@oracle.com> References: <4f13cf57-0bd9-768c-c3a8-6e0931bb79b6@oracle.com> Message-ID: Looks good. /Erik On 2018-01-31 09:11, Phil Race wrote: > Adding build-dev and 2d-dev. > > -phil. > > On 01/31/2018 09:10 AM, Phil Race wrote: >> All UI apps are broken on Linux : >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-8196509 >> Webrev: http://cr.openjdk.java.net/~prr/8196509/ >> >> The fix (for now) is a straightforward reversion of the change here : >> http://hg.openjdk.java.net/jdk/client/rev/2f4fe7776a53 >> >> -phil > From philip.race at oracle.com Wed Jan 31 18:08:28 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 31 Jan 2018 10:08:28 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8196468 : Client jtreg ProblemList updates In-Reply-To: <6aeb4573-5c65-1585-5ab0-e35c7034032e@oracle.com> References: <6aeb4573-5c65-1585-5ab0-e35c7034032e@oracle.com> Message-ID: I need to update this before I push. v0 added 216 java/awt/Modal/FileDialog/FileDialogTKModal1Test.java 8196430 linux-all 217 java/awt/Modal/FileDialog/FileDialogTKModal2Test.java 8196430 linux-all 218 java/awt/Modal/FileDialog/FileDialogTKModal3Test.java 8196430 linux-all 219 java/awt/Modal/FileDialog/FileDialogTKModal4Test.java 8196430 linux-all 220 java/awt/Modal/FileDialog/FileDialogTKModal5Test.java 8196430 linux-all 221 java/awt/Modal/FileDialog/FileDialogTKModal6Test.java 8196430 linux-all But these tests were already excluded on windows+mac under a different ID .. Now adding this line, jtreg seems to prefer this new line and doesn't see that it should be ignoring the test on windows under the other ID. So you can only exclude a test under one ID .. even if failures are on different platforms and the causes are unrelated. I have removed the original one and made these entries platform generic. http://cr.openjdk.java.net/~prr/8196468.1/ -phil. On 01/30/2018 06:30 PM, Sergey Bylokhov wrote: > Looks fine. > > On 30/01/2018 16:07, Phil Race wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8196468 >> Webrev: http://cr.openjdk.java.net/~prr/8196468/ >> >> There's some noise in here as I moved the swing tests added last time >> to be listed >> next to other swing tests and grouped a few other tests together. >> >> The biggest additions are a lot of failures on linux that are filed >> as just a few bugs >> since they are likely the same underlying issue - probably a product >> /platform issue >> and some tests that jtreg says have errors. >> >> Most of the Windows additions here are tests that timeout for a >> variety of reasons. >> >> -phil. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Wed Jan 31 19:00:28 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 31 Jan 2018 11:00:28 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8196468 : Client jtreg ProblemList updates In-Reply-To: References: <6aeb4573-5c65-1585-5ab0-e35c7034032e@oracle.com> Message-ID: <840b7b38-6659-fcaf-91b9-5d983ccf2942@oracle.com> +1 On 31/01/2018 10:08, Phil Race wrote: > linux-all But these tests were already excluded on windows+mac under a > different ID .. Now adding this line, jtreg seems to prefer this new > line and doesn't see that it should be ignoring the test on windows > under the other ID. So you can only exclude a test under one ID .. even > if failures are on different platforms and the causes are unrelated. Maybe we can create RFE for jtreg? > > On 01/30/2018 06:30 PM, Sergey Bylokhov wrote: >> Looks fine. >> >> On 30/01/2018 16:07, Phil Race wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196468 >>> Webrev: http://cr.openjdk.java.net/~prr/8196468/ >>> >>> There's some noise in here as I moved the swing tests added last time >>> to be listed >>> next to other swing tests and grouped a few other tests together. >>> >>> The biggest additions are a lot of failures on linux that are filed >>> as just a few bugs >>> since they are likely the same underlying issue - probably a product >>> /platform issue >>> and some tests that jtreg says have errors. >>> >>> Most of the Windows additions here are tests that timeout for a >>> variety of reasons. >>> >>> -phil. >>> >> >> > -- Best regards, Sergey. From sgehwolf at redhat.com Wed Jan 31 19:59:26 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 31 Jan 2018 20:59:26 +0100 Subject: [OpenJDK 2D-Dev] RFR: JDK-8196218: [linux] libfontmanager should be linked against headless awt library In-Reply-To: <0caee810-84f0-e3eb-5e32-a331e2be4473@oracle.com> References: <1516983050.4518.21.camel@redhat.com> <6c63d26a-a056-99bd-c383-146784a4871c@oracle.com> <1516986142.4518.31.camel@redhat.com> <44fb0d96-b134-3fba-8ba8-bffa4fd2225f@oracle.com> <2d569244-42a1-c652-cf96-0761d22328bc@oracle.com> <1517218778.4106.10.camel@redhat.com> <4657791d-45ff-deb6-b092-b3b28963dd4f@oracle.com> <1517252031.4106.47.camel@redhat.com> <2479e9ec-18db-02fe-01bd-69ae29862173@oracle.com> <1517301748.4159.1.camel@redhat.com> <87a8ef58-4c83-42e2-59be-db23be9f4343@oracle.com> <1517331919.4159.39.camel@redhat.com> <0caee810-84f0-e3eb-5e32-a331e2be4473@oracle.com> Message-ID: <1517428766.4101.44.camel@redhat.com> Hi Phil, On Wed, 2018-01-31 at 08:49 -0800, Phil Race wrote: > Severin, > > Did you run any UI apps on a full (make all) build with the final > version of the patch applied ? > It appears to have completely broken all UI apps on Linux and about > 800 > UI tests failed last night. > Exception in thread "AWT-EventQueue-0" > java.lang.NullPointerException: > native ops missing > at > java.desktop/sun.java2d.xr.XRSurfaceData.freeXSDOPicture(Native > Method) I cannot reproduce this. SwingSet2 works fine on my Fedora 27 desktop. > An exploded build is fine but the images build (what we ship) is > broken. Exploded build works fine for me too. Which linux systems are those? > I think I'll need to back this out. OK. > A good thing it was pushed to client .. Yes. Thanks, Severin > -phil. > > On 01/30/2018 09:16 AM, Phil Race wrote: > > On 1/30/2018 9:05 AM, Severin Gehwolf wrote: > > > On Tue, 2018-01-30 at 08:36 -0800, Erik Joelsson wrote: > > > > I found your job and it's all successful. Something is up with > > > > the > > > > service though. I'm pinging the relevant people here. > > > > > > Phil, Erik: Where should I push this to? jdk or client? > > > > A good question. Since it has passed builds on all platforms, then > > we > > know that is fine, > > but if you push to jdk/jdk there may not be any actual testing of > > the > > effects of the change before > > inclusion in a promotion. > > > > So you can push to jdk/jdk but it is a calculated risk .. if it > > were > > me I'd push to jdk/client. > > > > -phil. > > > > > > > > http://hg.openjdk.java.net/jdk/client/ > > > > > > or > > > > > > http://hg.openjdk.java.net/jdk/jdk/ > > > > > > Thanks, > > > Severin > >