-
Bug
-
Resolution: Duplicate
-
P4
-
22, 23
ADDITIONAL SYSTEM INFORMATION :
Java 23, both Oracle and OpenJDK, on Windows 10 and 11 as well as OpenJDK 23 on macOS 14.
Our Swing-based test application running our proprietary layout engine to create images in multiple threads.
A DESCRIPTION OF THE PROBLEM :
Testing our product, RealObjects PDFreactor, with Java 23, using our local Swing-based test application, we encountered random VM crashes, reporting different kinds of errors. While they happen randomly, it rarely takes more than 5-10 tries to get another one. Each try requires a restart of the Application/VM, as it seems that once the critical line of code has run successfully, the issue won't occur until restarting.
The issue does not occur when there is no or little multi-threading (4 threads works fine, 8 shows the issue and being near the amount of CPU cores shows it quicker), but we could not pinpoint what has to be happening in the other threads. It seems the involvement of BufferedImages, presumably drawing text into them, is relevant, but that is speculation.
The line causing the crash can be found below (Steps to Reproduce). It is the first time that the application creates a GlyphVector for a complex (Hebrew) character and in RTL direction. It may also be the first GlyphVector explicitly created.
We hope the attached error report files, especially the 1st and 4th, help you pinpoint the issue without being able to replicate it first.
While this issue persists, we must recommend our customers to not upgrade to Java 23.
REGRESSION : Last worked in version 22.0.2
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
The line causing the actual error is as follows:
awtFont.layoutGlyphVector(new FontRenderContext(new AffineTransform(), true, true), "\u05d0".toCharArray(), 0, 1, Font.LAYOUT_RIGHT_TO_LEFT | Font.LAYOUT_NO_START_CONTEXT | Font.LAYOUT_NO_LIMIT_CONTEXT);
(awtFont is Tinos regular at a size of 16, but using a random system font still reproduces crashes)
However it does require activity in other threads to happen (see above) and there is always some randomness to it.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
VM does not crash
ACTUAL -
VM crashes
CUSTOMER SUBMITTED WORKAROUND :
Making the same layoutGlyphVector call, with the first available system font, as early as possible seems to avoid the issue for the rest of the runtime.
FREQUENCY : often
Java 23, both Oracle and OpenJDK, on Windows 10 and 11 as well as OpenJDK 23 on macOS 14.
Our Swing-based test application running our proprietary layout engine to create images in multiple threads.
A DESCRIPTION OF THE PROBLEM :
Testing our product, RealObjects PDFreactor, with Java 23, using our local Swing-based test application, we encountered random VM crashes, reporting different kinds of errors. While they happen randomly, it rarely takes more than 5-10 tries to get another one. Each try requires a restart of the Application/VM, as it seems that once the critical line of code has run successfully, the issue won't occur until restarting.
The issue does not occur when there is no or little multi-threading (4 threads works fine, 8 shows the issue and being near the amount of CPU cores shows it quicker), but we could not pinpoint what has to be happening in the other threads. It seems the involvement of BufferedImages, presumably drawing text into them, is relevant, but that is speculation.
The line causing the crash can be found below (Steps to Reproduce). It is the first time that the application creates a GlyphVector for a complex (Hebrew) character and in RTL direction. It may also be the first GlyphVector explicitly created.
We hope the attached error report files, especially the 1st and 4th, help you pinpoint the issue without being able to replicate it first.
While this issue persists, we must recommend our customers to not upgrade to Java 23.
REGRESSION : Last worked in version 22.0.2
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
The line causing the actual error is as follows:
awtFont.layoutGlyphVector(new FontRenderContext(new AffineTransform(), true, true), "\u05d0".toCharArray(), 0, 1, Font.LAYOUT_RIGHT_TO_LEFT | Font.LAYOUT_NO_START_CONTEXT | Font.LAYOUT_NO_LIMIT_CONTEXT);
(awtFont is Tinos regular at a size of 16, but using a random system font still reproduces crashes)
However it does require activity in other threads to happen (see above) and there is always some randomness to it.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
VM does not crash
ACTUAL -
VM crashes
CUSTOMER SUBMITTED WORKAROUND :
Making the same layoutGlyphVector call, with the first available system font, as early as possible seems to avoid the issue for the rest of the runtime.
FREQUENCY : often
- duplicates
-
JDK-8337753 Target class of upcall stub may be unloaded
- Resolved