Bug 1776915
| Summary: | java.awt.Graphics.drawLine() hangs up when drawing too long line | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Simeon Andreev <simeon.andreev> | ||||
| Component: | java-11-openjdk | Assignee: | Mario Torre <neugens> | ||||
| Status: | CLOSED ERRATA | QA Contact: | OpenJDK QA <java-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 7.4 | CC: | ahughes, dbhole, jandrlik, jvanek, loskutov, mmillson, neugens, saahamad, sgehwolf | ||||
| Target Milestone: | rc | Flags: | ahughes:
mirror+
|
||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | java-11-openjdk-11.0.7.3-0.1.ea.el7 | Doc Type: | If docs needed, set a value | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2020-09-29 19:53:57 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
Please note, that the problem does not appear with "-Dsun.java2d.opengl=true" system flag, which means, that one rendering implementation in Java works properly, but other does not. Please also note, that there is already a related bug reported to OpenJDK, which shows exact the problem we see :https://bugs.openjdk.java.net/browse/JDK-4265778 Running the RenderBug example hangs Java for the use case 1 (the comment in the RenderBug code says however that "This correctly and quickly draws the line" which is obviously not the case). So to summarize: we need the patch that resolves the hang for the NON-OpenGL rendering engine, because our application must also run on systems that do not have display drivers with OpenGL support. Note: this bug is filled against Java 11, but Java 8 shows exact same issue and it would be great to have the patch backported from 11 to 8 too. Created attachment 1644754 [details]
Uses longs in relevant areas for Bresenham line rendering
This is not a proposed fix, but it's meant to test a viable solution and to see if there are more areas that need attention.
I filed an upstream bug to track this: https://bugs.openjdk.java.net/browse/JDK-8235904 sanity only. no exact test for this behavior except possible upstream jtreg @Jiri - The customer require the build of this bug for testing purpose. Do we have an option to share the latest build for their testing purposes? @Jiri - I did not hear any response from you, Could you please answer my question which I have asked in the last comment? Hi Sarfaraz, If you could let me know the architecture & RHEL version they need a build for, I can let you have one to pass on for testing. Thanks. (In reply to Andrew John Hughes from comment #15) > Hi Sarfaraz, > If you could let me know the architecture & RHEL version they need a build > for, I can let you have one to pass on for testing. > Thanks. "They" are "we" and we need it for RHEL 7.4 / x86 / 64 bit. uname -a Linux xxx 3.10.0-862.3.2.el7.x86_64 #1 SMP Tue May 15 18:22:15 EDT 2018 x86_64 x86_64 x86_64 GNU/Linux Ok, I can do a test build for RHEL 7.4, but you do realise that OpenJDK in RHEL 7.4 is already outdated with respect to multiple security updates and will not be updated with this fix either? This fix will appear in the April security update (11.0.7) and so will make its way to RHEL 7.8 that way, rather than via this bug. However, we don't support anything beyond the current y and z stream, so there won't be an update to the RHEL 7.4 packages. (In reply to Andrew John Hughes from comment #17) > Ok, I can do a test build for RHEL 7.4, but you do realise that OpenJDK in > RHEL 7.4 is already outdated with respect to multiple security updates and > will not be updated with this fix either? You mean, Open JDK 1.8 will be not updated or RHEL 7.4? So far we are on 1.8.0_181-b13 and we hope that the patch will be backported to 1.8 stream too, so we can manually update it even if it is not officially included in RHEL 7.4 packages. Regarding RHEL 7.4 - you know, we've are so happy to release last product version shipped on RHEL 5.8 this year, so we start to support "only" 7.4+ RHEL from next product version. The environment we are talking about is semiconductor test factories, they are very reluctant to *any* change. So the "modern" 7.4 RHEL will stay for years for many customers. > This fix will appear in the April security update (11.0.7) and so will make > its way to RHEL 7.8 that way, rather than via this bug. However, we don't > support anything beyond the current y and z stream, so there won't be an > update to the RHEL 7.4 packages. Thanks, that is fine. OpenJDK 11 & 8 (or 7 for that matter) won't be updated in RHEL 7.4. Is it a build of OpenJDK 8 you want? I was assuming OpenJDK 11 as that's what the bug is filed against. (In reply to Andrew John Hughes from comment #19) > OpenJDK 11 & 8 (or 7 for that matter) won't be updated in RHEL 7.4. > > Is it a build of OpenJDK 8 you want? Yes, sure. We don't want a new RHEL build, because we will be unable to use it anyway with the update policies we have. > I was assuming OpenJDK 11 as that's > what the bug is filed against. Yes, see comment 3. 11 is a must, 8 is a (very) nice to have, because 8 is still *the* most used platform (we have the product running on 11, but that is not released yet). Do I see it right, the fix is *planned* to be ported to Java 1.8.0_252 via https://bugs.openjdk.java.net/browse/JDK-8239871 and to Java 11.0.7 via https://bugs.openjdk.java.net/browse/JDK-8238754? Can you please confirm that? Could you please give an estimation when the 1.8.0_252 / 11.0.7 OpenJDK packages will be available from RH? Thanks. (In reply to Andrey Loskutov from comment #26) > Do I see it right, the fix is *planned* to be ported to Java 1.8.0_252 via > https://bugs.openjdk.java.net/browse/JDK-8239871 and to Java 11.0.7 via > https://bugs.openjdk.java.net/browse/JDK-8238754? Can you please confirm > that? Could you please give an estimation when the 1.8.0_252 / 11.0.7 > OpenJDK packages will be available from RH? Thanks. I already pushed the fix in the OpenJDK repositories, is not just "planned" (unless of course it needs to be reverted for some reason), so OpenJDK 8u252 and 11.0.7 will have the fix (again, unless they need to be pulled out for some reason). As for when, OpenJDK 8u *should* be released on April 14th 2020: https://wiki.openjdk.java.net/display/jdk8u The Red Hat builds usually follow suite. Of course this is a tentative date since a number of things can affect it, Andrew can probably give some better answer though. (In reply to Mario Torre from comment #27) > (In reply to Andrey Loskutov from comment #26) > > Do I see it right, the fix is *planned* to be ported to Java 1.8.0_252 via > > https://bugs.openjdk.java.net/browse/JDK-8239871 and to Java 11.0.7 via > > https://bugs.openjdk.java.net/browse/JDK-8238754? Can you please confirm > > that? Could you please give an estimation when the 1.8.0_252 / 11.0.7 > > OpenJDK packages will be available from RH? Thanks. > > I already pushed the fix in the OpenJDK repositories, is not just "planned" > (unless of course it needs to be reverted for some reason), so OpenJDK 8u252 > and 11.0.7 will have the fix (again, unless they need to be pulled out for > some reason). > > As for when, OpenJDK 8u *should* be released on April 14th 2020: > > https://wiki.openjdk.java.net/display/jdk8u > > The Red Hat builds usually follow suite. Of course this is a tentative date > since a number of things can affect it, Andrew can probably give some better > answer though. I did mention this back in Comment #17. The changes will be in the April security update (8u252 & 11.0.7) and I'd expect them to be available in RHEL in the second half of that month (depending on release processes, testing, etc.). I'm working on the builds for this at the moment. However, these updates will only be to versions of RHEL supported as of mid-April (7.8, 7.9, 8.1 & 8.2, plus 6.10 for OpenJDK 8 only). We no longer update RHEL 7.4. system: RHEL-7.9-20200507
build: java-11-openjdk-11.0.7.10-6.el7
tested:
import java.awt.Graphics;
import javax.swing.JFrame;
import javax.swing.JPanel;
public class DrawLine extends JPanel {
public static void main(String[] args) {
JFrame frame = new JFrame();
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
frame.setSize(500, 500);
frame.add(new DrawLine());
frame.setVisible(true);
}
@Override
public void paintComponent(Graphics g) {
System.out.println("drawing ...");
// g.drawLine(0, 0, 33004, 33004); // ok
g.drawLine(0, 0, 34005, 34005); // hang
System.out.println("drawn");
}
}
results:
no hangs observed, drew line just fine.
AFAIAC, the issue has been solved in ojdk11
system: RHEL-7.9-20200507
build: java-1.8.0-openjdk-1.8.0.252.b09-3.el7
tested:
import java.awt.Graphics;
import javax.swing.JFrame;
import javax.swing.JPanel;
public class DrawLine extends JPanel {
public static void main(String[] args) {
JFrame frame = new JFrame();
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
frame.setSize(500, 500);
frame.add(new DrawLine());
frame.setVisible(true);
}
@Override
public void paintComponent(Graphics g) {
System.out.println("drawing ...");
// g.drawLine(0, 0, 33004, 33004); // ok
g.drawLine(0, 0, 34005, 34005); // hang
System.out.println("drawn");
}
}
results:
no hangs observed either, drew line just fine.
solved in ojdk8 as well, VERIFIED
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (java-11-openjdk bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:3919 |
Description of problem: When drawing a really long line with AWT on Linux, the JVM hangs. Version-Release number of selected component (if applicable): OpenJDK 1.8 (checked on 232) OpenJDK 11 (checked on 11.0.5) How reproducible: Steps to Reproduce: 1. Run the following snippet: package test; import java.awt.Graphics; import javax.swing.JFrame; import javax.swing.JPanel; public class DrawLine extends JPanel { public static void main(String[] args) { JFrame frame = new JFrame(); frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); frame.setSize(500, 500); frame.add(new DrawLine()); frame.setVisible(true); } @Override public void paintComponent(Graphics g) { System.out.println("drawing ..."); // g.drawLine(0, 0, 33004, 33004); // ok g.drawLine(0, 0, 34005, 34005); // hang System.out.println("drawn"); } } Actual results: Observe a hang. Expected results: Expected no hang. Additional info: jstack from the hang with Java 1.8 232: "AWT-EventQueue-0" #22 prio=6 os_prio=0 tid=0x00007ffff02eb800 nid=0xb595 runnable [0x00007fff9eec0000] java.lang.Thread.State: RUNNABLE at sun.java2d.xr.XRDrawLine.clipCoordinates(XRDrawLine.java:320) at sun.java2d.xr.XRDrawLine.rasterizeLine(XRDrawLine.java:71) at sun.java2d.xr.XRRenderer.drawLine(XRRenderer.java:94) at sun.java2d.pipe.ValidatePipe.drawLine(ValidatePipe.java:62) at sun.java2d.SunGraphics2D.drawLine(SunGraphics2D.java:2234) at DrawLine.paintComponent(DrawLine.java:22) at javax.swing.JComponent.paint(JComponent.java:1056) at javax.swing.JComponent.paintChildren(JComponent.java:889) - locked <0x00000007155e72d0> (a java.awt.Component$AWTTreeLock) at javax.swing.JComponent.paint(JComponent.java:1065) at javax.swing.JComponent.paintChildren(JComponent.java:889) - locked <0x00000007155e72d0> (a java.awt.Component$AWTTreeLock) at javax.swing.JComponent.paint(JComponent.java:1065) at javax.swing.JLayeredPane.paint(JLayeredPane.java:586) at javax.swing.JComponent.paintChildren(JComponent.java:889) - locked <0x00000007155e72d0> (a java.awt.Component$AWTTreeLock) at javax.swing.JComponent.paintToOffscreen(JComponent.java:5217) at javax.swing.BufferStrategyPaintManager.paint(BufferStrategyPaintManager.java:290) at javax.swing.RepaintManager.paint(RepaintManager.java:1272) at javax.swing.JComponent.paint(JComponent.java:1042) at java.awt.GraphicsCallback$PaintCallback.run(GraphicsCallback.java:39) at sun.awt.SunGraphicsCallback.runOneComponent(SunGraphicsCallback.java:79) at sun.awt.SunGraphicsCallback.runComponents(SunGraphicsCallback.java:116) at java.awt.Container.paint(Container.java:1978) at java.awt.Window.paint(Window.java:3906) at javax.swing.RepaintManager$4.run(RepaintManager.java:842) at javax.swing.RepaintManager$4.run(RepaintManager.java:814) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74) at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:814) at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:789) at javax.swing.RepaintManager.prePaintDirtyRegions(RepaintManager.java:738) at javax.swing.RepaintManager.access$1200(RepaintManager.java:64) at javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1732) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758) at java.awt.EventQueue.access$500(EventQueue.java:97) at java.awt.EventQueue$3.run(EventQueue.java:709) at java.awt.EventQueue$3.run(EventQueue.java:703) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74) at java.awt.EventQueue.dispatchEvent(EventQueue.java:728) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:205) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) jstack from hang with Java 11.0.5: "AWT-EventQueue-0" #24 prio=6 os_prio=0 cpu=8199.35ms elapsed=8.23s tid=0x00007ffff092d000 nid=0xb626 runnable [0x00007fff75ff4000] java.lang.Thread.State: RUNNABLE at sun.java2d.xr.XRDrawLine.clipCoordinates(java.desktop.5/XRDrawLine.java:318) at sun.java2d.xr.XRDrawLine.rasterizeLine(java.desktop.5/XRDrawLine.java:69) at sun.java2d.xr.XRRenderer.drawLine(java.desktop.5/XRRenderer.java:94) at sun.java2d.pipe.ValidatePipe.drawLine(java.desktop.5/ValidatePipe.java:62) at sun.java2d.SunGraphics2D.drawLine(java.desktop.5/SunGraphics2D.java:2235) at test.DrawLine.paintComponent(TestJava11/DrawLine.java:23) at javax.swing.JComponent.paint(java.desktop.5/JComponent.java:1074) at javax.swing.JComponent.paintChildren(java.desktop.5/JComponent.java:907) - locked <0x000000067d41db48> (a java.awt.Component$AWTTreeLock) at javax.swing.JComponent.paint(java.desktop.5/JComponent.java:1083) at javax.swing.JComponent.paintChildren(java.desktop.5/JComponent.java:907) - locked <0x000000067d41db48> (a java.awt.Component$AWTTreeLock) at javax.swing.JComponent.paint(java.desktop.5/JComponent.java:1083) at javax.swing.JLayeredPane.paint(java.desktop.5/JLayeredPane.java:590) at javax.swing.JComponent.paintChildren(java.desktop.5/JComponent.java:907) - locked <0x000000067d41db48> (a java.awt.Component$AWTTreeLock) at javax.swing.JComponent.paintToOffscreen(java.desktop.5/JComponent.java:5262) at javax.swing.BufferStrategyPaintManager.paint(java.desktop.5/BufferStrategyPaintManager.java:246) at javax.swing.RepaintManager.paint(java.desktop.5/RepaintManager.java:1323) at javax.swing.JComponent.paint(java.desktop.5/JComponent.java:1060) at java.awt.GraphicsCallback$PaintCallback.run(java.desktop.5/GraphicsCallback.java:39) at sun.awt.SunGraphicsCallback.runOneComponent(java.desktop.5/SunGraphicsCallback.java:78) at sun.awt.SunGraphicsCallback.runComponents(java.desktop.5/SunGraphicsCallback.java:115) at java.awt.Container.paint(java.desktop.5/Container.java:2002) at java.awt.Window.paint(java.desktop.5/Window.java:3940) at javax.swing.RepaintManager$4.run(java.desktop.5/RepaintManager.java:876) at javax.swing.RepaintManager$4.run(java.desktop.5/RepaintManager.java:848) at java.security.AccessController.doPrivileged(java.base.5/Native Method) at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(java.base.5/ProtectionDomain.java:85) at javax.swing.RepaintManager.paintDirtyRegions(java.desktop.5/RepaintManager.java:848) at javax.swing.RepaintManager.paintDirtyRegions(java.desktop.5/RepaintManager.java:823) at javax.swing.RepaintManager.prePaintDirtyRegions(java.desktop.5/RepaintManager.java:772) at javax.swing.RepaintManager$ProcessingRunnable.run(java.desktop.5/RepaintManager.java:1890) at java.awt.event.InvocationEvent.dispatch(java.desktop.5/InvocationEvent.java:313) at java.awt.EventQueue.dispatchEventImpl(java.desktop.5/EventQueue.java:770) at java.awt.EventQueue$4.run(java.desktop.5/EventQueue.java:721) at java.awt.EventQueue$4.run(java.desktop.5/EventQueue.java:715) at java.security.AccessController.doPrivileged(java.base.5/Native Method) at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(java.base.5/ProtectionDomain.java:85) at java.awt.EventQueue.dispatchEvent(java.desktop.5/EventQueue.java:740) at java.awt.EventDispatchThread.pumpOneEventForFilters(java.desktop.5/EventDispatchThread.java:203) at java.awt.EventDispatchThread.pumpEventsForFilter(java.desktop.5/EventDispatchThread.java:124) at java.awt.EventDispatchThread.pumpEventsForHierarchy(java.desktop.5/EventDispatchThread.java:113) at java.awt.EventDispatchThread.pumpEvents(java.desktop.5/EventDispatchThread.java:109) at java.awt.EventDispatchThread.pumpEvents(java.desktop.5/EventDispatchThread.java:101) at java.awt.EventDispatchThread.run(java.desktop.5/EventDispatchThread.java:90) I've also opened a RHEL support case, but I'm being asked for log files which I don't know how to produce: https://access.redhat.com/support/cases/#/case/02527617 There are a number of OpenJDK bugs that seem related, most of which are closed. I found this one, which is still open: https://bugs.openjdk.java.net/browse/JDK-4265778