JDK-8201539 : Crash in DirectWrite CreateBitmap code when running TestFX test suite
  • Type: Bug
  • Component: javafx
  • Sub-Component: graphics
  • Affected Version: 10,openjfx11
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_2012
  • CPU: x86_64
  • Submitted: 2018-04-13
  • Updated: 2020-03-23
  • Resolved: 2019-03-13
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 Other
8u231Fixed openjfx11.0.7Fixed
Related Reports
Relates :  
JDK-8207159 - Update ICU to version 62.1
Relates :  
JDK-8187147 - Remove T2K from JavaFX
Description
Running the TestFX test suite using JDK 10 crashes in DirectWrite CreateBitmap with the following stack trace:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007fffe2c74e80, pid=3000, tid=600
#
# JRE version: Java(TM) SE Runtime Environment (10.0+46) (build 10+46)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (10+46, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)
# Problematic frame:
# C  [javafx_font.dll+0x4e80]
#
# Core dump will be written. Default location: C:\projects\testfx\subprojects\testfx-core\hs_err_pid3000.mdmp
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
---------------  S U M M A R Y ------------
Command Line: -Dorg.gradle.native=false -Dfile.encoding=windows-1252 -Duser.country=US -Duser.language=en -Duser.variant -ea -Djava.awt.headless=true -Dtestfx.robot=glass -Dtestfx.headless=true -Dprism.order=sw -Dprism.text=t2k worker.org.gradle.process.internal.worker.GradleWorkerMain 'Gradle Test Executor 1'
Host: Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz, 2 cores, 2G,  Windows Server 2012 R2 , 64 bit Build 9600 (6.3.9600.17415)
Time: Fri Apr 13 02:07:48 2018 Coordinated Universal Time elapsed time: 5 seconds (0d 0h 0m 5s)
---------------  T H R E A D  ---------------
Current thread (0x000000405f666800):  JavaThread "QuantumRenderer-0" daemon [_thread_in_native, id=600, stack(0x0000004061600000,0x0000004061700000)]
Stack: [0x0000004061600000,0x0000004061700000],  sp=0x00000040616fc9c0,  free space=1010k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [javafx_font.dll+0x4e80]
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  com.sun.javafx.font.directwrite.OS.CreateBitmap(JIIII)J+0 javafx.graphics@10
j  com.sun.javafx.font.directwrite.IWICImagingFactory.CreateBitmap(IIII)Lcom/sun/javafx/font/directwrite/IWICBitmap;+9 javafx.graphics@10
...

I have attached the crash log.

This was originally filed on github: https://github.com/javafxports/openjdk-jfx/issues/66

This was discovered when they upgraded to JDK 10, but is likely a preexisting bug. The test sets the "-Dprism.text=t2k" flag, which used to force T2K prior to JDK 10. Since T2K was removed in JDK 10, this flag is now ignored and the native font code is used.
Comments
OK +1. And thanks for confirming that 1) In a normal desktop run, D3D also initializes COM so our unloading had not caused problems there 2) this means that we leave this initialised until the Prism Render thread exits and dispose only when the app is shutting down. So the fix could have been just to comment out the uninitialize ..
17-04-2019
Changeset: e687603602c1 Author: kcr Date: 2019-03-12 17:56 -0700 URL: http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/e687603602c1 8201539: Crash in DirectWrite CreateBitmap code when running TestFX test suite Summary: Defer CoUninitialize call to thread exit using dispose hook Reviewed-by: kcr, mennen Contributed-by: pyokagan@gmail.com
13-03-2019
Too late for openjfx11; targeting for openjfx12.
24-08-2018
Somewhat interestingly the crash can be prevented by commenting out the un-initialization of COM (after the Windows Imaging Component factory is created): In directwrite.cpp: /* Unload COM as no other COM objects will be create directly */ - CoUninitialize(); + //CoUninitialize(); return SUCCEEDED(hr) ? (jlong)result : NULL; Of course, that will lead to other problems, but it may provide the necessary insight for someone to realize a fix. At least, that's what I'm hoping.
10-08-2018
The crash is happening the first time DW is invoked to render a glyph This crash was reproduced with a small program (meaning any program that uses text) with the following incantation Kevin provided. It is using a local build of fx, since we don't bundle monocle in what is shipped. java @build/testrun.args -Dmonocle.platform=Headless -Dglass.platform=Monocle -Dprism.order=sw -Dprism.verbose=true -cp apps/toys/Hello/dist/Hello.jar hello.HelloFontSize What this implies is that Monocle is not initialising some native Windows resource needed for DirectWrite, and most likely folks had worked this out a long time ago and hence used -Dprism.text=t2k .. but that is now gone, and was never in open source anyway. But now that it is gone from all builds there is probably no way to support this headless testing on Windows. -Dprism.order=d3d cures the crash but almost certainly that won't render to the headless surface and so will be useless (verification of this would be nice to have). What will it take to fix this ? That is unclear. hopefully it is just missing initialisation that won't conflict with the headless mode. But it may be more complex than that ..
13-04-2018