This repository has been archived by the owner on Jun 24, 2021. It is now read-only.
Java 10 + Monocle = JVM Crash (TestFX test suite) #66
Labels
bug
Something isn't working
Comments
|
Is it possible that you were somehow falling back to T2K when running with JDK 9? The native font implementation, which calls DirectWrite on Windows platforms, has been the default since JDK 8, but we would fall back to T2K on Windows platforms without the necessary support (or via |
|
Answering my own question, I see this in your log: which means you were running T2K with JDK 9 and earlier. That flag is now ignored, so you are running the native font code with JDK 10. So that at least explains why the upgrade to JDK 10 has triggered this bug. |
|
I filed JDK-8201539 in JBS. |
|
That makes a lot of sense, thanks so much for tracking that down. I always wondered why we used that argument... 😆 |
This was referenced Apr 13, 2018
|
If we trust the native back-trace, it says the access violation occurs at |
|
@ararunprasad You were very helpful with the MathML bug (#71), do you think you could provide a little guidance on this one? |
|
@brcolow , let me take a look. |
|
@brcolow @ararunprasad We roughly know what the problem is: Some initialization that is done by either the D3D pipeline or Glass (either is sufficient) is needed to allow the DirectWrite calls used by the native font code to work. |
pyokagan
added a commit
to pyokagan/addressbook-level4
that referenced
this issue
Jun 30, 2018
Due to a JavaFX bug[1], JDK 10 on Windows will fail to run tests in headless mode. As such, let's warn developers against using JDK 10 on Windows in our documentation, and recommend that they use JDK 9 instead. Some developers who have both JDK 9 and JDK 10 installed on their systems may have trouble coaxing Gradle to use JDK 10. As such, to make it easier to troubleshoot the setup of such developers, let's teach build.gradle to print a warning to console if it detects that it is running with JDK 10 on Windows. [1] javafxports/openjdk-jfx#66
pyokagan
added a commit
to pyokagan/addressbook-level4
that referenced
this issue
Jun 30, 2018
Due to a JavaFX bug[1], JDK 10 on Windows will fail to run tests in headless mode. As such, let's warn developers against using JDK 10 on Windows in our documentation, and recommend that they use JDK 9 instead. Some developers who have both JDK 9 and JDK 10 installed on their systems may have trouble coaxing Gradle to use JDK 10. As such, to make it easier to troubleshoot the setup of such developers, let's teach build.gradle to print a warning to console if it detects that it is running with JDK 10 on Windows. [1] javafxports/openjdk-jfx#66
pyokagan
added a commit
to pyokagan/addressbook-level4
that referenced
this issue
Jul 3, 2018
Due to a JavaFX bug[1], JDK 10 on Windows will fail to run tests in headless mode. As such, let's warn developers against using JDK 10 on Windows in our documentation, and recommend that they use JDK 9 instead. Some developers who have both JDK 9 and JDK 10 installed on their systems may have trouble coaxing Gradle to use JDK 10. As such, to make it easier to troubleshoot the setup of such developers, let's teach build.gradle to print a warning to console if it detects that it is running with JDK 10 on Windows. [1] javafxports/openjdk-jfx#66
|
To get started on this issue, I took a look at the source code to figure out where the crash is happening, and that is here: /* IWICImagingFactory*/
JNIEXPORT jlong JNICALL OS_NATIVE(CreateBitmap)
(JNIEnv *env, jclass that, jlong arg0, jint arg1, jint arg2, jint arg3, jint arg4)
{
IWICBitmap* result = NULL;
GUID pixelFormat;
switch (arg3) {
case com_sun_javafx_font_directwrite_OS_GUID_WICPixelFormat8bppGray:pixelFormat = GUID_WICPixelFormat8bppGray; break;
case com_sun_javafx_font_directwrite_OS_GUID_WICPixelFormat8bppAlpha:pixelFormat = GUID_WICPixelFormat8bppAlpha; break;
case com_sun_javafx_font_directwrite_OS_GUID_WICPixelFormat16bppGray: pixelFormat = GUID_WICPixelFormat16bppGray; break;
case com_sun_javafx_font_directwrite_OS_GUID_WICPixelFormat24bppRGB: pixelFormat = GUID_WICPixelFormat24bppRGB; break;
case com_sun_javafx_font_directwrite_OS_GUID_WICPixelFormat24bppBGR: pixelFormat = GUID_WICPixelFormat24bppBGR; break;
case com_sun_javafx_font_directwrite_OS_GUID_WICPixelFormat32bppBGR: pixelFormat = GUID_WICPixelFormat32bppBGR; break;
case com_sun_javafx_font_directwrite_OS_GUID_WICPixelFormat32bppBGRA: pixelFormat = GUID_WICPixelFormat32bppBGRA; break;
case com_sun_javafx_font_directwrite_OS_GUID_WICPixelFormat32bppPBGRA: pixelFormat = GUID_WICPixelFormat32bppPBGRA; break;
case com_sun_javafx_font_directwrite_OS_GUID_WICPixelFormat32bppGrayFloat: pixelFormat = GUID_WICPixelFormat32bppGrayFloat; break;
case com_sun_javafx_font_directwrite_OS_GUID_WICPixelFormat32bppRGBA: pixelFormat = GUID_WICPixelFormat32bppRGBA; break;
case com_sun_javafx_font_directwrite_OS_GUID_WICPixelFormat32bppPRGBA: pixelFormat = GUID_WICPixelFormat32bppPRGBA; break;
}
HRESULT hr = ((IWICImagingFactory *)arg0)->CreateBitmap(arg1, arg2, (REFWICPixelFormatGUID)pixelFormat, (WICBitmapCreateCacheOption)arg4, &result);
return SUCCEEDED(hr) ? (jlong)result : NULL;
}It seems that which is implemented as native code in JNIEXPORT jlong JNICALL OS_NATIVE(_1WICCreateImagingFactory)
(JNIEnv *env, jclass that)
{
/* This routine initialize COM in order to create an WICImagingFactory.
* It runs on the prism thread and expects no other codes in this thread
* to interface with COM.
* Note: This method is called by DWFactory a single time.
*/
HRESULT hr = CoInitializeEx(NULL, COINIT_APARTMENTTHREADED | COINIT_DISABLE_OLE1DDE);
/* This means COM has been initialize with a different concurrency model.
* This should never happen. */
if (hr == RPC_E_CHANGED_MODE) return NULL;
IWICImagingFactory* result = NULL;
hr = CoCreateInstance(
CLSID_WICImagingFactory,
NULL,
CLSCTX_INPROC_SERVER,
IID_PPV_ARGS(&result)
);
/* Unload COM as no other COM objects will be create directly */
CoUninitialize();
return SUCCEEDED(hr) ? (jlong)result : NULL;I will try and investigate further. Edit: I found something kind of interesting with regards to Also, is it reliable to trust the java backtrace in the crash report, or is the native backtrace more reliable? Piggy-backing off your comment @kevinrushforth - is there any chance you could be more specific? Is it that Monocle needs to initialize something with respect to DirectWrite that is only being initialized by Glass? Edit 2: I don't think I'm working on compiling OpenJFX locally on my Windows development machine, but for some reason the first build is taking hours upon hours (seems to be stalling at Edit 3: Got a first successful local build of OpenJFX. I don't have cygwin installed, so I think the docs are incorrect in requiring Cygwin. It may only be working because I have WSL installed, though. Anyways, to compile locally I had to make some very small tweaks to the gradle build file, and I also created a powershell script that may be useful for others, I will open a PR for that soon-ish. |
SamCarlberg
added a commit
to SamCarlberg/shuffleboard
that referenced
this issue
Jul 31, 2018
Since headless TestFX is broken on Windows: javafxports/openjdk-jfx#66
|
Alright, I was able to debug using a locally built JavaFX and Visual Studio 2017 Community: javafx_font.dll!Java_com_sun_javafx_font_directwrite_OS_CreateBitmap(JNIEnv_ * env=0x000001f2e1ec3a70, _jclass * that=0x0000003f492fd0e8, __int64 arg0=2142694496368, long arg1=256, long arg2=256, long arg3=8, long arg4=1) Line 2359 The crash happens on this line:
Dissasembly: call qword ptr [rax+88] <--- I believe this is calling the function CreateBitmap on arg0
The docs for It seems it is normal to call Just wanted to post my progress, will update as I get more information. Debugger screenshot:
|
|
The changes in this commit seem to stop the crash for me (unless for some bewitching reason logging statements are having some effect or maybe after a couple tries without restarting it works?): but I can't easily tell because compilation takes so long. If someone could test it with the changes (@kevinrushforth @ararunprasad ) and LMK if I'm seeing an apparition or not, that would be much appreciated. Then we could narrow down which change it is. |
|
I was able to prevent the crash with only the following change to JNIEXPORT jlong JNICALL OS_NATIVE(_1WICCreateImagingFactory)
(JNIEnv *env, jclass that)
{
/* This routine initialize COM in order to create an WICImagingFactory.
* It runs on the prism thread and expects no other codes in this thread
* to interface with COM.
* Note: This method is called by DWFactory a single time.
*/
HRESULT hr = CoInitializeEx(NULL, COINIT_APARTMENTTHREADED | COINIT_DISABLE_OLE1DDE);
/* This means COM has been initialize with a different concurrency model.
* This should never happen. */
if (hr == RPC_E_CHANGED_MODE) return NULL;
IWICImagingFactory* result = NULL;
hr = CoCreateInstance(
- CLSID_WICImagingFactory
+ CLSID_WICImagingFactory1,
NULL,
CLSCTX_INPROC_SERVER,
IID_PPV_ARGS(&result)
);
+ if (hr == REGDB_E_CLASSNOTREG) {
+ hr = CoCreateInstance(
+ CLSID_WICImagingFactory,
+ NULL,
+ CLSCTX_INPROC_SERVER,
+ IID_PPV_ARGS(&result)
+ );
+ }
/* Unload COM as no other COM objects will be create directly */
CoUninitialize();
return SUCCEEDED(hr) ? (jlong)result : NULL;
}As soon as someone can re-produce the fix I'm seeing, I'll open a PR (I have a hard time believing it was this easy...). |
|
@brcolow I can take a look early next week. As this is a P2 bug, we can still get a fix into openjfx 11 if a safe fix can be found. |
|
I'm not sure if https://ci.appveyor.com/project/brcolow/openjdk-jfx/build/master%20267?fullLog=true proves that it fixes the crash or not, because I'm not sure if text is ever rendered to the screen without |
|
@kevinrushforth Do you think you will have time to take a look by tomorrow (Wednesday)? I know you are busy. Or anyone else that can build OpenJFX locally on Windows - let me know (and save Kevin the work!). |
|
I hope so... I'll put it on my list of reviews for tomorrow. |
|
I ran a quick test, and it still crashes for me. |
|
Huh...interesting. Okay, thanks. I will look more deeply into this. |
|
Check out this build which crashes (which only has the small changeset I mentioned above): Now compare that to this build, with the same test (no crash there, and indeed no where on any other tests): So it seems that the full changes (those in this PR): Are enough to stop the crash, probably at the expense of a memory leak as I mentioned earlier. Can you confirm? Thanks. Edit: I messed up the PR I linked to, there are too many changes, let me fix that. |
|
I can confirm that with the patched referenced above, it does not crash. The only difference between that and the patch I tried last night was the following: This is an interesting observation that may lead to a solution, but is not something we would want to use directly. |
|
I can approve, that the workaround @meszarv mentioned actually works. Only problem is: You need to really run it before any FxToolkit code, which will most likely require static initialization blocks in many cases and clever class loading prediction. I would test the fix kindly provided by @kevinrushforth but unfortunately it has not been released yet. |
|
The fix will be in the next early access build of JavaFX 13 (build 2). |
JanMosigItemis
added a commit
to JanMosigItemis/dodo
that referenced
this issue
Mar 14, 2019
fzdy1914
added a commit
to fzdy1914/NUS-CS2103-Inventory-Manager
that referenced
this issue
Mar 21, 2019
For headless test task, 'prism.order' property is used to choose the
graph renderer to use. Currently, we specify this property to be 'sw'
for all platforms.
However, this property triggers a bug of openjdk-jfx with headless
mode [1]. This property will cause Java Runtime Error for Windows OS
including AppVeyor:
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffd95b64879, pid=1476, tid=2640
#
# JRE version: OpenJDK Runtime Environment (11.0.1+13) (build 11.0.1+13)
# Java VM: OpenJDK 64-Bit Server VM (11.0.1+13, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)
# Problematic frame:
# C [javafx_font.dll+0x4879]
This bug has been identified and will be fixed in future release [2].
Let's set 'prism.order' property to be 'd3d' on Windows OS but retain
it to be 'sw' on other platforms as a temporary workaround to solve
the problem.
[1] javafxports/openjdk-jfx#66
[2] javafxports/openjdk-jfx#66 (comment)
fzdy1914
added a commit
to fzdy1914/NUS-CS2103-Inventory-Manager
that referenced
this issue
Mar 21, 2019
For headless test task, 'prism.order' property is used to choose the
graph renderer to use. Currently, we specify this property to be 'sw'
for all platforms.
However, this property triggers a bug of openjdk-jfx with headless
mode [1]. This property will cause Java Runtime Error for Windows OS
including AppVeyor:
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffd95b64879, pid=1476, tid=2640
#
# JRE version: OpenJDK Runtime Environment (11.0.1+13) (build 11.0.1+13)
# Java VM: OpenJDK 64-Bit Server VM (11.0.1+13, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)
# Problematic frame:
# C [javafx_font.dll+0x4879]
This bug has been identified and will be fixed in future release [2].
Let's set 'prism.order' property to be 'd3d' on Windows OS but retain
it to be 'sw' on other platforms as a temporary workaround to solve
the problem.
[1] javafxports/openjdk-jfx#66
[2] javafxports/openjdk-jfx#66 (comment)
fzdy1914
added a commit
to fzdy1914/NUS-CS2103-Inventory-Manager
that referenced
this issue
Mar 21, 2019
For headless test task, 'prism.order' property is used to choose the
graph renderer to use. Currently, we specify this property to be 'sw'
for all platforms.
However, this property triggers a bug of openjdk-jfx with headless
mode [1]. This property will cause Java Runtime Error for Windows OS
including AppVeyor:
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffd95b64879, pid=1476, tid=2640
#
# JRE version: OpenJDK Runtime Environment (11.0.1+13) (build 11.0.1+13)
# Java VM: OpenJDK 64-Bit Server VM (11.0.1+13, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)
# Problematic frame:
# C [javafx_font.dll+0x4879]
This bug has been identified and will be fixed in future release [2].
Let's set 'prism.order' property to be 'd3d' on Windows OS but retain
it to be 'sw' on other platforms as a temporary workaround to solve
the problem.
[1] javafxports/openjdk-jfx#66
[2] javafxports/openjdk-jfx#66 (comment)
fzdy1914
added a commit
to fzdy1914/NUS-CS2103-Inventory-Manager
that referenced
this issue
Mar 21, 2019
For headless test task, 'prism.order' property is used to choose the
graph renderer to use. Currently, we specify this property to be 'sw'.
However, this property triggers a bug of openjdk-jfx with headless
mode [1]. This property will cause Java Runtime Error for Windows OS
including AppVeyor:
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffd95b64879, pid=1476, tid=2640
#
# JRE version: OpenJDK Runtime Environment (11.0.1+13) (build 11.0.1+13)
# Java VM: OpenJDK 64-Bit Server VM (11.0.1+13, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)
# Problematic frame:
# C [javafx_font.dll+0x4879]
This bug has been identified and will be fixed in future release [2].
Let's use the workaround suggested [3] to solve the problem.
[1] javafxports/openjdk-jfx#66
[2] javafxports/openjdk-jfx#66 (comment)
[3] javafxports/openjdk-jfx#66 (comment)
fzdy1914
added a commit
to fzdy1914/NUS-CS2103-Inventory-Manager
that referenced
this issue
Mar 24, 2019
We currently advertise that we support "JDK 8". However, the public
updates of Java SE 8 for personal users will end soon [1].
JDK 11 is the next Long-Term-Support (LTS) release after JDK 8 [1].
It is better for us to keep updated with the latest release of JDK.
Let's update our target JDK to version 11, with the following steps:
* We use openjfx-monocle version jdk-11+26 since that is the latest
version of openjfx-monocle that supports JDK 11 [2].
* We bump the target and source compatibility of Gradle to JDK11.
* We update Travis and AppVoyer configs to use JDK11 as runtime
environment.
* We remove the add-on in Travis config because it is redundant for
JDK 11 [3].
* We make it clear in the User Guide / Developer Guide that we only
support JDK 11 (not JDK 8, 9, 10).
[1] https://www.oracle.com/technetwork/java/java-se-support-roadmap.html
[2] https://github.com/TestFX/Monocle
[3] https://www.deps.co/guides/travis-ci-latest-java/ (+5 squashed commit)
Squashed commit:
[46a3e78] Add workaround to solve headless test failure on Windows OS
For headless test task, 'prism.order' property is used to choose the
graph renderer to use. Currently, we specify this property to be 'sw'.
However, this property triggers a bug of openjdk-jfx with headless
mode [1]. This property will cause Java Runtime Error for Windows OS
including AppVeyor:
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffd95b64879, pid=1476, tid=2640
#
# JRE version: OpenJDK Runtime Environment (11.0.1+13) (build 11.0.1+13)
# Java VM: OpenJDK 64-Bit Server VM (11.0.1+13, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)
# Problematic frame:
# C [javafx_font.dll+0x4879]
This bug has been identified and will be fixed in future release [2].
Let's use the workaround suggested [3] to solve the problem.
[1] javafxports/openjdk-jfx#66
[2] javafxports/openjdk-jfx#66 (comment)
[3] javafxports/openjdk-jfx#66 (comment)
[3e4620a] build.gradle: add javafx runtime dependency for other platforms
We have added the platform specific javafx runtime dependency, so the
addressbook is able to run locally.
However, the jar file generated on one OS cannot run on other OS. The
reason is that, java SE cannot initialize the graph render correctly
without corresponding javafx dependency for that other OS.
Let's add the javafx runtime dependency for all platforms (MacOS,
Window, Linux) so the jar file generated on one OS is able to run in
other OS [1].
The order of dependency is important because it effects the way Gradle
group dependency tree.
[1]https://stackoverflow.com/questions/52653836/maven-shade-javafx-runtime-components-are-missing/52654791#52654791
[3d9a8b3] change the entry point of addressbook
After we add the javafx runtime dependency, addressbook is still unable
to run in a jdk11 environment. It gives an error of below:
Error: JavaFX runtime components are missing, and are required to run this application
This error comes from sun.launcher.LauncherHelper in the java.base
module. The reason for this is that the Main app extends Application
and has a main method. If that is the case, the LauncherHelper will
check for the javafx.graphics module to be present as a named module.
If that module is not present, the launch is aborted. Hence, having
the JavaFX libraries as jars on the classpath is not allowed in this
case [1].
This is more like a JDK 11 problem which cannot be solved elegantly.
One simple workaround is to have a separate main class that doesn't
extend Application. Hence it doesn't do the check on javafx.graphics
module, and when the required jars are on the classpath, it works fine.
Let's add another main class to be the new entry point of addressbook
to solve this problem [2].
[1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-June/021977.html
[2] https://stackoverflow.com/questions/52653836/maven-shade-javafx-runtime-components-are-missing/52654791#52654791
[ab48626] build.gradle: add javafx runtime dependency
JavaFX is not distributed with Oracle JDK any more from JDK11
onwards [1]. Our code uses javafx as our client platform. So it is
unable to be compiled in JDK11 anymore.
As we are moving to JDK11, let's add javafx runtime dependency to
gradle.
Meanwhile, the dependency provided are platform specific. Let's use the
SystemUtils api provided by Apache [2] to specify the version of javafx
dependency. A buildscript block is also added to declare external
dependencies used for the build script [3].
[1] https://blogs.oracle.com/java-platform-group/the-future-of-javafx-and-other-java-client-roadmap-updates
[2] http://commons.apache.org/proper/commons-lang/javadocs/api-release/index.html
[3] https://docs.gradle.org/current/userguide/tutorial_using_tasks.html#sec:build_script_external_dependencies
[9f736ce] build.gradle: fix checkstyle plugin failure
The `checkstyle` plugin of Gradle fails in JDK11 and gives the error
below:
Unable to create Root Module: config ...
The main reason is that, in JDK11, the `user.dir` cannot be reset by
Gradle [1]. So, checkstyle plugin is unable to locate the suppressions
file correctly.
Let's add ` config_loc` variable suggested by Gradle to solve the
problem [1].
[1] gradle/gradle#8286
fzdy1914
added a commit
to fzdy1914/NUS-CS2103-Inventory-Manager
that referenced
this issue
Mar 31, 2019
For headless test task, 'prism.order' property is used to choose the
graph renderer to use. Currently, we specify this property to be 'sw'.
However, this property triggers a bug of openjdk-jfx with headless
mode [1]. This property will cause Java Runtime Error for Windows OS
including AppVeyor:
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffd95b64879, pid=1476, tid=2640
#
# JRE version: OpenJDK Runtime Environment (11.0.1+13) (build 11.0.1+13)
# Java VM: OpenJDK 64-Bit Server VM (11.0.1+13, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)
# Problematic frame:
# C [javafx_font.dll+0x4879]
This bug has been identified and will be fixed in future release [2].
Let's use the workaround suggested [3] to solve the problem.
[1] javafxports/openjdk-jfx#66
[2] javafxports/openjdk-jfx#66 (comment)
[3] javafxports/openjdk-jfx#66 (comment)
fzdy1914
added a commit
to fzdy1914/NUS-CS2103-Inventory-Manager
that referenced
this issue
Mar 31, 2019
For headless test task, 'prism.order' property is used to choose the
graph renderer to use. Currently, we specify this property to be 'sw'.
However, this property triggers a bug of openjdk-jfx with headless
mode [1]. This property will cause Java Runtime Error for Windows OS
including AppVeyor:
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffd95b64879, pid=1476, tid=2640
#
# JRE version: OpenJDK Runtime Environment (11.0.1+13) (build 11.0.1+13)
# Java VM: OpenJDK 64-Bit Server VM (11.0.1+13, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)
# Problematic frame:
# C [javafx_font.dll+0x4879]
This bug has been identified and will be fixed in future release [2].
Let's use the workaround suggested [3] to solve the problem.
[1] javafxports/openjdk-jfx#66
[2] javafxports/openjdk-jfx#66 (comment)
[3] javafxports/openjdk-jfx#66 (comment)
fzdy1914
added a commit
to fzdy1914/NUS-CS2103-Inventory-Manager
that referenced
this issue
Apr 1, 2019
For headless test task, 'prism.order' property is used to choose the
graph renderer to use. Currently, we specify this property to be 'sw'.
However, this property triggers a bug of openjdk-jfx with headless
mode [1]. This property will cause Java Runtime Error for Windows OS
including AppVeyor:
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffd95b64879, pid=1476, tid=2640
#
# JRE version: OpenJDK Runtime Environment (11.0.1+13) (build 11.0.1+13)
# Java VM: OpenJDK 64-Bit Server VM (11.0.1+13, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)
# Problematic frame:
# C [javafx_font.dll+0x4879]
This bug has been identified and will be fixed in future release [2].
Let's use the workaround suggested [3] to solve the problem.
[1] javafxports/openjdk-jfx#66
[2] javafxports/openjdk-jfx#66 (comment)
[3] javafxports/openjdk-jfx#66 (comment)
fzdy1914
added a commit
to fzdy1914/NUS-CS2103-Inventory-Manager
that referenced
this issue
Apr 1, 2019
For headless test task, 'prism.order' property is used to choose the
graph renderer to use. Currently, we specify this property to be 'sw'.
However, this property triggers a bug of openjdk-jfx with headless
mode [1]. This property will cause Java Runtime Error for Windows OS
including AppVeyor:
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffd95b64879, pid=1476, tid=2640
#
# JRE version: OpenJDK Runtime Environment (11.0.1+13) (build 11.0.1+13)
# Java VM: OpenJDK 64-Bit Server VM (11.0.1+13, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)
# Problematic frame:
# C [javafx_font.dll+0x4879]
This bug has been identified and will be fixed in future release [2].
Let's use the workaround suggested [3] to solve the problem.
[1] javafxports/openjdk-jfx#66
[2] javafxports/openjdk-jfx#66 (comment)
[3] javafxports/openjdk-jfx#66 (comment)
fzdy1914
added a commit
to fzdy1914/NUS-CS2103-Inventory-Manager
that referenced
this issue
Apr 2, 2019
For headless test task, 'prism.order' property is used to choose the
graph renderer to use. Currently, we specify this property to be 'sw'.
However, this property triggers a bug of openjdk-jfx with headless
mode [1]. This property will cause Java Runtime Error for Windows OS
including AppVeyor:
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffd95b64879, pid=1476, tid=2640
#
# JRE version: OpenJDK Runtime Environment (11.0.1+13) (build 11.0.1+13)
# Java VM: OpenJDK 64-Bit Server VM (11.0.1+13, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)
# Problematic frame:
# C [javafx_font.dll+0x4879]
This bug has been identified and will be fixed in future release [2].
Let's use the workaround suggested [3] to solve the problem.
[1] javafxports/openjdk-jfx#66
[2] javafxports/openjdk-jfx#66 (comment)
[3] javafxports/openjdk-jfx#66 (comment)
fzdy1914
added a commit
to fzdy1914/NUS-CS2103-Inventory-Manager
that referenced
this issue
Apr 2, 2019
For headless test task, 'prism.order' property is used to choose the
graph renderer to use. Currently, we specify this property to be 'sw'.
However, this property triggers a bug of openjdk-jfx with headless
mode [1]. This property will cause Java Runtime Error for Windows OS
including AppVeyor:
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffd95b64879, pid=1476, tid=2640
#
# JRE version: OpenJDK Runtime Environment (11.0.1+13) (build 11.0.1+13)
# Java VM: OpenJDK 64-Bit Server VM (11.0.1+13, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)
# Problematic frame:
# C [javafx_font.dll+0x4879]
This bug has been identified and will be fixed in future release [2].
Let's use the workaround suggested [3] to solve the problem.
[1] javafxports/openjdk-jfx#66
[2] javafxports/openjdk-jfx#66 (comment)
[3] javafxports/openjdk-jfx#66 (comment)
fzdy1914
added a commit
to fzdy1914/NUS-CS2103-Inventory-Manager
that referenced
this issue
Apr 11, 2019
For headless test task, 'prism.order' property is used to choose the
graph renderer to use. Currently, we specify this property to be 'sw'.
However, this property triggers a bug of openjdk-jfx with headless
mode [1]. This property will cause Java Runtime Error for Windows OS
including AppVeyor:
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffd95b64879, pid=1476, tid=2640
#
# JRE version: OpenJDK Runtime Environment (11.0.1+13) (build 11.0.1+13)
# Java VM: OpenJDK 64-Bit Server VM (11.0.1+13, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)
# Problematic frame:
# C [javafx_font.dll+0x4879]
This bug has been identified and will be fixed in future release [2].
There is a workaround suggested which adds static initialization
blocks to load required library before any FxToolkit code [3].
For ui test, the FxToolkit code is firstly used in UiPartRule. For
system test, the FxToolkit code is firstly used in
SystemTestSetupHelper. Let's add the static initialization blocks to
above two classes to solve the problem.
[1] javafxports/openjdk-jfx#66
[2] javafxports/openjdk-jfx#66 (comment)
[3] javafxports/openjdk-jfx#66 (comment)
fzdy1914
added a commit
to fzdy1914/NUS-CS2103-Inventory-Manager
that referenced
this issue
Apr 12, 2019
For headless test task, 'prism.order' property is used to choose the
graph renderer to use. Currently, we specify this property to be 'sw'.
However, this property triggers a bug of openjdk-jfx with headless
mode [1]. This property will cause Java Runtime Error for Windows OS
including AppVeyor:
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffd95b64879, pid=1476, tid=2640
#
# JRE version: OpenJDK Runtime Environment (11.0.1+13) (build 11.0.1+13)
# Java VM: OpenJDK 64-Bit Server VM (11.0.1+13, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)
# Problematic frame:
# C [javafx_font.dll+0x4879]
This bug has been identified and will be fixed in future release [2].
There is a workaround suggested which adds static initialization
blocks to load required library before any FxToolkit code [3].
For ui test, the FxToolkit code is firstly used in UiPartRule. For
system test, the FxToolkit code is firstly used in
SystemTestSetupHelper. Let's add the static initialization blocks to
above two classes to solve the problem.
[1] javafxports/openjdk-jfx#66
[2] javafxports/openjdk-jfx#66 (comment)
[3] javafxports/openjdk-jfx#66 (comment)
fzdy1914
added a commit
to fzdy1914/NUS-CS2103-Inventory-Manager
that referenced
this issue
Apr 16, 2019
For headless test task, 'prism.order' property is used to choose the
graph renderer to use. Currently, we specify this property to be 'sw'.
However, this property triggers a bug of openjdk-jfx with headless
mode [1]. This property will cause Java Runtime Error for Windows OS
including AppVeyor:
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffd95b64879, pid=1476, tid=2640
#
# JRE version: OpenJDK Runtime Environment (11.0.1+13) (build 11.0.1+13)
# Java VM: OpenJDK 64-Bit Server VM (11.0.1+13, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)
# Problematic frame:
# C [javafx_font.dll+0x4879]
This bug has been identified and will be fixed in future release [2].
There is a workaround suggested which adds static initialization
blocks to load required library before any FxToolkit code [3].
Java will initialize base classes first before classes of instance
members [4] [5]. For all GUI tests, they uses GuiUnitTest or
AddressBookSystemTest as their base class. Let's add the static
initialization blocks to these two classes to solve the problem.
[1] javafxports/openjdk-jfx#66
[2] javafxports/openjdk-jfx#66 (comment)
[3] javafxports/openjdk-jfx#66 (comment)
[4] https://docs.oracle.com/javase/specs/jls/se8/html/jls-12.html#jls-12.4
[5] https://docs.oracle.com/javase/specs/jls/se8/html/jls-12.html#jls-12.5
fzdy1914
added a commit
to fzdy1914/NUS-CS2103-Inventory-Manager
that referenced
this issue
Apr 16, 2019
For headless test task, 'prism.order' property is used to choose the
graph renderer to use. Currently, we specify this property to be 'sw'.
However, this property triggers a bug of openjdk-jfx with headless
mode [1]. This property will cause Java Runtime Error for Windows OS
including AppVeyor:
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffd95b64879, pid=1476, tid=2640
#
# JRE version: OpenJDK Runtime Environment (11.0.1+13) (build 11.0.1+13)
# Java VM: OpenJDK 64-Bit Server VM (11.0.1+13, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)
# Problematic frame:
# C [javafx_font.dll+0x4879]
This bug has been identified and will be fixed in future release [2].
There is a workaround suggested which adds static initialization
blocks to load required library before any FxToolkit code [3].
Java will initialize base classes first before classes of instance
members [4] [5]. For all GUI tests, they uses GuiUnitTest or
AddressBookSystemTest as their base class. Let's add the static
initialization blocks to these two classes to solve the problem.
[1] javafxports/openjdk-jfx#66
[2] javafxports/openjdk-jfx#66 (comment)
[3] javafxports/openjdk-jfx#66 (comment)
[4] https://docs.oracle.com/javase/specs/jls/se8/html/jls-12.html#jls-12.4
[5] https://docs.oracle.com/javase/specs/jls/se8/html/jls-12.html#jls-12.5
fzdy1914
added a commit
to fzdy1914/NUS-CS2103-Inventory-Manager
that referenced
this issue
Apr 16, 2019
For headless test task, 'prism.order' property is used to choose the
graph renderer to use. Currently, we specify this property to be 'sw'.
However, this property triggers a bug of openjdk-jfx with headless
mode [1]. This property will cause Java Runtime Error for Windows OS
including AppVeyor:
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffd95b64879, pid=1476, tid=2640
#
# JRE version: OpenJDK Runtime Environment (11.0.1+13) (build 11.0.1+13)
# Java VM: OpenJDK 64-Bit Server VM (11.0.1+13, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)
# Problematic frame:
# C [javafx_font.dll+0x4879]
This bug has been identified and will be fixed in future release [2].
There is a workaround suggested which adds static initialization
blocks to load required library before any FxToolkit code [3].
Java will initialize base classes first before classes of instance
members [4] [5]. For all GUI tests, they uses GuiUnitTest or
AddressBookSystemTest as their base class. Let's add the static
initialization blocks to these two classes to solve the problem.
[1] javafxports/openjdk-jfx#66
[2] javafxports/openjdk-jfx#66 (comment)
[3] javafxports/openjdk-jfx#66 (comment)
[4] https://docs.oracle.com/javase/specs/jls/se8/html/jls-12.html#jls-12.4
[5] https://docs.oracle.com/javase/specs/jls/se8/html/jls-12.html#jls-12.5
fzdy1914
added a commit
to fzdy1914/NUS-CS2103-Inventory-Manager
that referenced
this issue
Apr 23, 2019
For headless test task, 'prism.order' property is used to choose the
graph renderer to use. Currently, we specify this property to be 'sw'.
However, this property triggers a bug of openjdk-jfx with headless
mode [1]. This property will cause Java Runtime Error for Windows OS
including AppVeyor:
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffd95b64879, pid=1476, tid=2640
#
# JRE version: OpenJDK Runtime Environment (11.0.1+13) (build 11.0.1+13)
# Java VM: OpenJDK 64-Bit Server VM (11.0.1+13, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)
# Problematic frame:
# C [javafx_font.dll+0x4879]
This bug has been identified and will be fixed in future release [2].
There is a workaround suggested which adds static initialization
blocks to load required library before any FxToolkit code [3].
Java will initialize base classes first before classes of instance
members [4] [5]. For all GUI tests, they uses GuiUnitTest or
AddressBookSystemTest as their base class. Let's add the static
initialization blocks to these two classes to solve the problem.
[1] javafxports/openjdk-jfx#66
[2] javafxports/openjdk-jfx#66 (comment)
[3] javafxports/openjdk-jfx#66 (comment)
[4] https://docs.oracle.com/javase/specs/jls/se8/html/jls-12.html#jls-12.4
[5] https://docs.oracle.com/javase/specs/jls/se8/html/jls-12.html#jls-12.5
fzdy1914
added a commit
to fzdy1914/NUS-CS2103-Inventory-Manager
that referenced
this issue
Apr 24, 2019
For headless test task, 'prism.order' property is used to choose the
graph renderer to use. Currently, we specify this property to be 'sw'.
However, this property triggers a bug of openjdk-jfx with headless
mode [1]. This property will cause Java Runtime Error for Windows OS
including AppVeyor:
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffd95b64879, pid=1476, tid=2640
#
# JRE version: OpenJDK Runtime Environment (11.0.1+13) (build 11.0.1+13)
# Java VM: OpenJDK 64-Bit Server VM (11.0.1+13, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)
# Problematic frame:
# C [javafx_font.dll+0x4879]
This bug has been identified and will be fixed in future release [2].
There is a workaround suggested which adds static initialization
blocks to load required library before any FxToolkit code [3].
Java will initialize base classes first before classes of instance
members [4] [5]. For all GUI tests, they uses GuiUnitTest or
AddressBookSystemTest as their base class. Let's add the static
initialization blocks to these two classes to solve the problem.
[1] javafxports/openjdk-jfx#66
[2] javafxports/openjdk-jfx#66 (comment)
[3] javafxports/openjdk-jfx#66 (comment)
[4] https://docs.oracle.com/javase/specs/jls/se8/html/jls-12.html#jls-12.4
[5] https://docs.oracle.com/javase/specs/jls/se8/html/jls-12.html#jls-12.5
fzdy1914
added a commit
to fzdy1914/NUS-CS2103-Inventory-Manager
that referenced
this issue
Apr 24, 2019
For headless test task, 'prism.order' property is used to choose the
graph renderer to use. Currently, we specify this property to be 'sw'.
However, this property triggers a bug of openjdk-jfx with headless
mode [1]. This property will cause Java Runtime Error for Windows OS
including AppVeyor:
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffd95b64879, pid=1476, tid=2640
#
# JRE version: OpenJDK Runtime Environment (11.0.1+13) (build 11.0.1+13)
# Java VM: OpenJDK 64-Bit Server VM (11.0.1+13, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)
# Problematic frame:
# C [javafx_font.dll+0x4879]
This bug has been identified and will be fixed in future release [2].
There is a workaround suggested which adds static initialization
blocks to load required library before any FxToolkit code [3].
Java will initialize base classes first before classes of instance
members [4] [5]. For all GUI tests, they uses GuiUnitTest or
AddressBookSystemTest as their base class. Let's add the static
initialization blocks to these two classes to solve the problem.
[1] javafxports/openjdk-jfx#66
[2] javafxports/openjdk-jfx#66 (comment)
[3] javafxports/openjdk-jfx#66 (comment)
[4] https://docs.oracle.com/javase/specs/jls/se8/html/jls-12.html#jls-12.4
[5] https://docs.oracle.com/javase/specs/jls/se8/html/jls-12.html#jls-12.5
fzdy1914
added a commit
to fzdy1914/NUS-CS2103-Inventory-Manager
that referenced
this issue
Apr 24, 2019
For headless test task, 'prism.order' property is used to choose the
graph renderer to use. Currently, we specify this property to be 'sw'.
However, this property triggers a bug of openjdk-jfx with headless
mode [1]. This property will cause Java Runtime Error for Windows OS
including AppVeyor:
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffd95b64879, pid=1476, tid=2640
#
# JRE version: OpenJDK Runtime Environment (11.0.1+13) (build 11.0.1+13)
# Java VM: OpenJDK 64-Bit Server VM (11.0.1+13, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)
# Problematic frame:
# C [javafx_font.dll+0x4879]
This bug has been identified and will be fixed in future release [2].
There is a workaround suggested which adds static initialization
blocks to load required library before any FxToolkit code [3].
Java will initialize base classes first before classes of instance
members [4] [5]. For all GUI tests, they uses GuiUnitTest or
AddressBookSystemTest as their base class. Let's add the static
initialization blocks to these two classes to solve the problem.
[1] javafxports/openjdk-jfx#66
[2] javafxports/openjdk-jfx#66 (comment)
[3] javafxports/openjdk-jfx#66 (comment)
[4] https://docs.oracle.com/javase/specs/jls/se8/html/jls-12.html#jls-12.4
[5] https://docs.oracle.com/javase/specs/jls/se8/html/jls-12.html#jls-12.5
fzdy1914
added a commit
to fzdy1914/NUS-CS2103-Inventory-Manager
that referenced
this issue
Apr 24, 2019
For headless test task, 'prism.order' property is used to choose the
graph renderer to use. Currently, we specify this property to be 'sw'.
However, this property triggers a bug of openjdk-jfx with headless
mode [1]. This property will cause Java Runtime Error for Windows OS
including AppVeyor:
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffd95b64879, pid=1476, tid=2640
#
# JRE version: OpenJDK Runtime Environment (11.0.1+13) (build 11.0.1+13)
# Java VM: OpenJDK 64-Bit Server VM (11.0.1+13, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)
# Problematic frame:
# C [javafx_font.dll+0x4879]
This bug has been identified and will be fixed in future release [2].
There is a workaround suggested which adds static initialization
blocks to load required library before any FxToolkit code [3].
Java will initialize base classes first before classes of instance
members [4] [5]. For all GUI tests, they uses GuiUnitTest or
AddressBookSystemTest as their base class. Let's add the static
initialization blocks to these two classes to solve the problem.
[1] javafxports/openjdk-jfx#66
[2] javafxports/openjdk-jfx#66 (comment)
[3] javafxports/openjdk-jfx#66 (comment)
[4] https://docs.oracle.com/javase/specs/jls/se8/html/jls-12.html#jls-12.4
[5] https://docs.oracle.com/javase/specs/jls/se8/html/jls-12.html#jls-12.5
fzdy1914
added a commit
to fzdy1914/NUS-CS2103-Inventory-Manager
that referenced
this issue
Apr 30, 2019
For headless test task, 'prism.order' property is used to choose the
graph renderer to use. Currently, we specify this property to be 'sw'.
However, this property triggers a bug of openjdk-jfx with headless
mode [1]. This property will cause Java Runtime Error for Windows OS
including AppVeyor:
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffd95b64879, pid=1476, tid=2640
#
# JRE version: OpenJDK Runtime Environment (11.0.1+13) (build 11.0.1+13)
# Java VM: OpenJDK 64-Bit Server VM (11.0.1+13, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)
# Problematic frame:
# C [javafx_font.dll+0x4879]
This bug has been identified and will be fixed in future release [2].
There is a workaround suggested which adds static initialization
blocks to load required library before any FxToolkit code [3].
Java will initialize base classes first before classes of instance
members [4] [5]. For all GUI tests, they uses GuiUnitTest or
AddressBookSystemTest as their base class. Let's add the static
initialization blocks to these two classes to solve the problem.
[1] javafxports/openjdk-jfx#66
[2] javafxports/openjdk-jfx#66 (comment)
[3] javafxports/openjdk-jfx#66 (comment)
[4] https://docs.oracle.com/javase/specs/jls/se8/html/jls-12.html#jls-12.4
[5] https://docs.oracle.com/javase/specs/jls/se8/html/jls-12.html#jls-12.5
fzdy1914
added a commit
to fzdy1914/NUS-CS2103-Inventory-Manager
that referenced
this issue
May 3, 2019
For headless test task, 'prism.order' property is used to choose the
graph renderer to use. Currently, we specify this property to be 'sw'.
However, this property triggers a bug of openjdk-jfx with headless
mode [1]. This property will cause Java Runtime Error for Windows OS
including AppVeyor:
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffd95b64879, pid=1476, tid=2640
#
# JRE version: OpenJDK Runtime Environment (11.0.1+13) (build 11.0.1+13)
# Java VM: OpenJDK 64-Bit Server VM (11.0.1+13, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)
# Problematic frame:
# C [javafx_font.dll+0x4879]
This bug has been identified and will be fixed in future release [2].
There is a workaround suggested which adds static initialization
blocks to load required library before any FxToolkit code [3].
Java will initialize base classes first before classes of instance
members [4] [5]. For all GUI tests, they uses GuiUnitTest or
AddressBookSystemTest as their base class. Let's add the static
initialization blocks to these two classes to solve the problem.
[1] javafxports/openjdk-jfx#66
[2] javafxports/openjdk-jfx#66 (comment)
[3] javafxports/openjdk-jfx#66 (comment)
[4] https://docs.oracle.com/javase/specs/jls/se8/html/jls-12.html#jls-12.4
[5] https://docs.oracle.com/javase/specs/jls/se8/html/jls-12.html#jls-12.5
fzdy1914
added a commit
to fzdy1914/NUS-CS2103-Inventory-Manager
that referenced
this issue
May 3, 2019
For headless test task, 'prism.order' property is used to choose the
graph renderer to use. Currently, we specify this property to be 'sw'.
However, this property triggers a bug of openjdk-jfx with headless
mode [1]. This property will cause Java Runtime Error for Windows OS
including AppVeyor:
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffd95b64879, pid=1476, tid=2640
#
# JRE version: OpenJDK Runtime Environment (11.0.1+13) (build 11.0.1+13)
# Java VM: OpenJDK 64-Bit Server VM (11.0.1+13, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)
# Problematic frame:
# C [javafx_font.dll+0x4879]
This bug has been identified and will be fixed in future release [2].
There is a workaround suggested which adds static initialization
blocks to load required library before any FxToolkit code [3].
Java will initialize base classes first before classes of instance
members [4] [5]. For all GUI tests, they uses GuiUnitTest or
AddressBookSystemTest as their base class. Let's add the static
initialization blocks to these two classes to solve the problem.
[1] javafxports/openjdk-jfx#66
[2] javafxports/openjdk-jfx#66 (comment)
[3] javafxports/openjdk-jfx#66 (comment)
[4] https://docs.oracle.com/javase/specs/jls/se8/html/jls-12.html#jls-12.4
[5] https://docs.oracle.com/javase/specs/jls/se8/html/jls-12.html#jls-12.5
grimreaper
pushed a commit
to PCGen/pcgen
that referenced
this issue
Aug 4, 2019
Added temporary fix for build error due to javafxports/openjdk-jfx#66
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
After adding a Java 10 build to our (TestFX) appveyor configuration, I am seeing a crash (every time at the same place):
https://ci.appveyor.com/project/testfx/testfx/build/master%201046/job/3pl22fioi0ut9juc#L492
It is triggered by this test.
I believe it is crashing in modules/javafx.graphics/src/main/native-font/directwrite.cpp in the
JNIEXPORT jlong JNICALL OS_NATIVE(CreateBitmap)method. This is somewhat strange because that file hasn't been modified since the javafx-font and javafx-font-native modules were open sourced (as RT-31139) so figuring out why this would precipitate a crash now in Java 10 is probably non-trivial.Here is the crash dump:
The text was updated successfully, but these errors were encountered: