RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1776915 - java.awt.Graphics.drawLine() hangs up when drawing too long line
Summary: java.awt.Graphics.drawLine() hangs up when drawing too long line
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: java-11-openjdk
Version: 7.4
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Mario Torre
QA Contact: OpenJDK QA
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-11-26 15:02 UTC by Simeon Andreev
Modified: 2023-09-07 21:06 UTC (History)
9 users (show)

Fixed In Version: java-11-openjdk-11.0.7.3-0.1.ea.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-09-29 19:53:57 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Uses longs in relevant areas for Bresenham line rendering (5.47 KB, patch)
2019-12-13 10:42 UTC, Mario Torre 		no flags Details | Diff
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2020:3919 0 None None None 2020-09-29 19:54:40 UTC
openjdk bug system JDK-8235904 0 None None None 2019-12-16 01:02:47 UTC

Description Simeon Andreev 2019-11-26 15:02:25 UTC 
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
Comment 3 Andrey Loskutov 2019-11-27 12:36:49 UTC 
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.
Comment 5 Mario Torre 2019-12-13 10:42:21 UTC 
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.
Comment 6 Mario Torre 2019-12-13 11:14:43 UTC 
I filed an upstream bug to track this:

https://bugs.openjdk.java.net/browse/JDK-8235904
Comment 12 jiri vanek 2020-01-31 16:43:21 UTC 
sanity only. no exact test for this behavior except possible upstream jtreg
Comment 13 Sarfaraz Ahamad 2020-02-22 14:28:27 UTC 
@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?
Comment 14 Sarfaraz Ahamad 2020-03-03 08:45:41 UTC 
@Jiri - I did not hear any response from you, Could you please answer my question which I have asked in the last comment?
Comment 15 Andrew John Hughes 2020-03-03 12:00:19 UTC 
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.
Comment 16 Andrey Loskutov 2020-03-03 12:16:19 UTC 
(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
Comment 17 Andrew John Hughes 2020-03-03 13:00:21 UTC 
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.
Comment 18 Andrey Loskutov 2020-03-03 13:11:41 UTC 
(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.
Comment 19 Andrew John Hughes 2020-03-03 13:32:04 UTC 
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.
Comment 20 Andrey Loskutov 2020-03-03 13:40:36 UTC 
(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).
Comment 26 Andrey Loskutov 2020-03-17 17:30:15 UTC 
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.
Comment 27 Mario Torre 2020-03-17 17:42:47 UTC 
(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.
Comment 28 Andrew John Hughes 2020-03-23 21:09:04 UTC 
(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.
Comment 33 jandrlik 2020-05-10 05:59:56 UTC 
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
Comment 34 jandrlik 2020-05-10 06:32:49 UTC 
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
Comment 36 errata-xmlrpc 2020-09-29 19:53:57 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.