Re: [OpenJDK 2D-Dev] RFR: 8028539: Endless loop in native code of sun.java2d.loops.ScaledBlit
That looks good. You bring up good points as well. The main thing I was worried about is hanging an automated regression test run if there is ever a regression... ...jim On 10/27/14 2:49 PM, Phil Race wrote: I can add othervm but each VM invocation slows down the overall testing time and I'd like to think this only will be run on versions that do not have the bug. I added the custom time out code so that I was not reliant on the harness to test. Certainly I can delete all of that and just go to @run main/othervm/timeout=60 60 up from 15 because it needs to include othervm overhead and avoid/minimise spurious failures See http://cr.openjdk.java.net/~prr/8028539.1/ -phil. On 10/27/2014 2:10 PM, Jim Graham wrote: The fix looks fine. Isn't there a timeout you can set on the unit test rather than rolling your own inside the test? Also, even if you interrupt the test, if the failure mode is an infinite loop in native code then the VM you are running in is probably not going to be happy. That only happens when the test fails, but is it worth running in a separate VM just in case? ...jim On 10/27/14 1:51 PM, Phil Race wrote: https://bugs.openjdk.java.net/browse/JDK-8028539 http://cr.openjdk.java.net/~prr/8028539/ The trigger for the bug is that there is a translate component on the graphics which overflows what can be stored in a integer, and the native code we reach cannot handle this. Although the sofware loops was hanging, additionally D3D and OGL on Windows were not clipping this properly. The rendering appeared on screen when it should have been clipped. The fix is to add a test to see if any value overflows and then punt to the TransformHelper code which can handle and clip this properly. -phil.
Re: [OpenJDK 2D-Dev] RFR: 8028539: Endless loop in native code of sun.java2d.loops.ScaledBlit
I can add othervm but each VM invocation slows down the overall testing time and I'd like to think this only will be run on versions that do not have the bug. I added the custom time out code so that I was not reliant on the harness to test. Certainly I can delete all of that and just go to @run main/othervm/timeout=60 60 up from 15 because it needs to include othervm overhead and avoid/minimise spurious failures See http://cr.openjdk.java.net/~prr/8028539.1/ -phil. On 10/27/2014 2:10 PM, Jim Graham wrote: The fix looks fine. Isn't there a timeout you can set on the unit test rather than rolling your own inside the test? Also, even if you interrupt the test, if the failure mode is an infinite loop in native code then the VM you are running in is probably not going to be happy. That only happens when the test fails, but is it worth running in a separate VM just in case? ...jim On 10/27/14 1:51 PM, Phil Race wrote: https://bugs.openjdk.java.net/browse/JDK-8028539 http://cr.openjdk.java.net/~prr/8028539/ The trigger for the bug is that there is a translate component on the graphics which overflows what can be stored in a integer, and the native code we reach cannot handle this. Although the sofware loops was hanging, additionally D3D and OGL on Windows were not clipping this properly. The rendering appeared on screen when it should have been clipped. The fix is to add a test to see if any value overflows and then punt to the TransformHelper code which can handle and clip this properly. -phil.
Re: [OpenJDK 2D-Dev] RFR: 8028539: Endless loop in native code of sun.java2d.loops.ScaledBlit
The fix looks fine. Isn't there a timeout you can set on the unit test rather than rolling your own inside the test? Also, even if you interrupt the test, if the failure mode is an infinite loop in native code then the VM you are running in is probably not going to be happy. That only happens when the test fails, but is it worth running in a separate VM just in case? ...jim On 10/27/14 1:51 PM, Phil Race wrote: https://bugs.openjdk.java.net/browse/JDK-8028539 http://cr.openjdk.java.net/~prr/8028539/ The trigger for the bug is that there is a translate component on the graphics which overflows what can be stored in a integer, and the native code we reach cannot handle this. Although the sofware loops was hanging, additionally D3D and OGL on Windows were not clipping this properly. The rendering appeared on screen when it should have been clipped. The fix is to add a test to see if any value overflows and then punt to the TransformHelper code which can handle and clip this properly. -phil.
[OpenJDK 2D-Dev] RFR: 8028539: Endless loop in native code of sun.java2d.loops.ScaledBlit
https://bugs.openjdk.java.net/browse/JDK-8028539 http://cr.openjdk.java.net/~prr/8028539/ The trigger for the bug is that there is a translate component on the graphics which overflows what can be stored in a integer, and the native code we reach cannot handle this. Although the sofware loops was hanging, additionally D3D and OGL on Windows were not clipping this properly. The rendering appeared on screen when it should have been clipped. The fix is to add a test to see if any value overflows and then punt to the TransformHelper code which can handle and clip this properly. -phil.
Re: [OpenJDK 2D-Dev] [9] Review Request: 8062164 Incorrect color conversion, when bicubic interpolation is used
Hi Sergey, In the test case you call new BufferedImage() with a Transparency constant which is essentially a random number to determine the type of BufferedImage since it is expecting its own values. You get lucky with the value of the integer as it turns out, but the test case really should be using the constants from BufferedImage in its own constructor instead (too bad we didn't have typed enums back when this was all happening). Also, a test case with an infinite loop should either have a timeout, or a limit on "retries" in the loop - just in case we ever run the test in an environment where VIs fail for some reason... ...jim On 10/27/14 8:57 AM, Sergey Bylokhov wrote: Hello. Please review the fix for jdk 9. Type of the temporary buffer in DrawImage.renderImageXform() is incorrect. Note that we blit this buffer to the destination, using next maskblit/blit: line 463: maskblit = MaskBlit.getFromCache(SurfaceType.IntArgbPre, sg.imageComp, dstType); line 489: blit = Blit.getFromCache(SurfaceType.IntArgbPre, sg.imageComp, dstType); Type of source surface is IntArgbPre in both cases, but the type of tmpBuffer is IntArgb. Bug: https://bugs.openjdk.java.net/browse/JDK-8062164 Webrev can be found at: http://cr.openjdk.java.net/~serb/8062164/webrev.01
Re: [OpenJDK 2D-Dev] RFR: JDK-8057830: Crash in Java2D Queue Flusher, OGLSD_SetScratchSurface
Hi, Hendrik. The fix looks good. webrev: http://cr.openjdk.java.net/~serb/Hendrik/8057830/webrev However, before we can accept fixes from you, you will need to have an OCA signed. Please find more details here: http://www.oracle.com/technetwork/community/oca-486395.html On 22.09.2014 12:19, Hendrik Schreiber wrote: Hi, Bug: https://bugs.openjdk.java.net/browse/JDK-8057830 On OS X, CGLGraphicsConfigInfo is destroyed by OGLGC_DestroyOGLGraphicsConfig, however the pointer to it still hangs around for a while and is not reset to NULL, until we get rid of it with a Disposer later on. In the meantime it appears to be possible that OGLSD_SetScratchSurface is called with the already destroyed CGLGraphicsConfigInfo as argument. The CGLGraphicsConfigInfo is not NULL, but its structs are in a bad state, most likely freed, leading to the observed crash. The suggested change does not solve the problem, of needing to NULL the pointer to CGLGraphicsConfigInfo right where it's destroyed in OGLRenderQueue.c (not really possible IMO). However, it improves the destruction by NULLing some of it struct members and thus allowing us in OGLSD_SetScratchSurface to test those for NULL values. I also added a trace call for when this happens, to aiding potentially creating a better fix in the future. Unfortunately, I have not been able to come up with a reasonable unit test for this, therefore I cannot be certain that it solves the problem. However, as the changes are minimal and obviously harmless, I would very much appreciate it, if somebody decided to sponsor and commit this patch. I have a live application out there based on 8u20 and this is the number one reason for user-reported crashes. Webrev: https://www.beatunes.com/download/webrev_8057830.zip I did a full clean OS X build to test the change. Before and after I encountered the same 11 jdk_2d failures (which made me wonder whether that is normal...). Cheers, -hendrik PS: I'm new to contributing OpenJDK patches, let me know, if I should have done it some other way. Thanks. -- Best regards, Sergey.
[OpenJDK 2D-Dev] [9] Review Request: 8062164 Incorrect color conversion, when bicubic interpolation is used
Hello. Please review the fix for jdk 9. Type of the temporary buffer in DrawImage.renderImageXform() is incorrect. Note that we blit this buffer to the destination, using next maskblit/blit: line 463: maskblit = MaskBlit.getFromCache(SurfaceType.IntArgbPre, sg.imageComp, dstType); line 489: blit = Blit.getFromCache(SurfaceType.IntArgbPre, sg.imageComp, dstType); Type of source surface is IntArgbPre in both cases, but the type of tmpBuffer is IntArgb. Bug: https://bugs.openjdk.java.net/browse/JDK-8062164 Webrev can be found at: http://cr.openjdk.java.net/~serb/8062164/webrev.01 -- Best regards, Sergey.
