JDK-8276809: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java shows JNI warning on Windows

[MBaesken]

The new test java/awt/font/JNICheck/FreeTypeScalerJNICheck.java introduced with https://bugs.openjdk.java.net/browse/JDK-8269223 adds -Xcheck:jni to an awt related test, and shows on Windows server 2019 the following JNI warning , so the test JNICheck/FreeTypeScalerJNICheck.java fails on this Windows version.

:stdErr:
Thu Oct 28 01:27:10 CEST 2021
stdout: [WARNING in native method: JNI call made without checking exceptions when required to from CallStaticVoidMethodV
at sun.awt.Win32GraphicsEnvironment.initDisplay(java.desktop@18.0.0.1-internal/Native Method)
at sun.awt.Win32GraphicsEnvironment.initDisplayWrapper(java.desktop@18.0.0.1-internal/Win32GraphicsEnvironment.java:95)
at sun.awt.Win32GraphicsEnvironment.(java.desktop@18.0.0.1-internal/Win32GraphicsEnvironment.java:63)
at sun.awt.PlatformGraphicsInfo.createGE(java.desktop@18.0.0.1-internal/PlatformGraphicsInfo.java:34)
at java.awt.GraphicsEnvironment$LocalGE.createGE(java.desktop@18.0.0.1-internal/GraphicsEnvironment.java:93)
at java.awt.GraphicsEnvironment$LocalGE.(java.desktop@18.0.0.1-internal/GraphicsEnvironment.java:84)
at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(java.desktop@18.0.0.1-internal/GraphicsEnvironment.java:106)
at FreeTypeScalerJNICheck.runTest(FreeTypeScalerJNICheck.java:53)
at FreeTypeScalerJNICheck.main(FreeTypeScalerJNICheck.java:44)

We can get rid of the warning by adjusting a JNU_CallStaticMethodByName call in awt_Win32GraphicsEnv.cpp .

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change must be properly reviewed

Issue

• JDK-8276809: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java shows JNI warning on Windows

Reviewers

• Christoph Langer (@RealCLanger - Reviewer) ⚠️ Review applies to 5d18a76

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/6306/head:pull/6306
$ git checkout pull/6306

Update a local copy of the PR:
$ git checkout pull/6306
$ git pull https://git.openjdk.java.net/jdk pull/6306/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 6306

View PR using the GUI difftool:
$ git pr show -t 6306

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/6306.diff

[bridgekeeper]

👋 Welcome back mbaesken! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@MBaesken The following label will be automatically applied to this pull request:

• client

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[mlbridge]

Webrevs

• 02: Full - Incremental (579bd889)
• 01: Full - Incremental (ab1101b3)
• 00: Full (5d18a76c)

[RealCLanger]

LGTM

[openjdk]

@MBaesken This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8276809: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java shows JNI warning on Windows

Reviewed-by: clanger

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 156 new commits pushed to the master branch:

• 7a046e0: 8277371: Remove unnecessary DefNewGeneration::ref_processor_init()
• 3a76d39: 8277324: C2 compilation fails with "bad AD file" on x86-32 after JDK-8276162 due to missing match rule
• 2f20b0d: 8273039: JShell crashes when naming variable or method "abstract" or "strictfp"
• f34f119: 8277213: CompileTask_lock is acquired out of order with MethodCompileQueue_lock
• 47564ca: 8275643: C2's unaryOp vector intrinsic does not properly handle LongVector.neg
• 2f0bde1: 8277102: Dubious PrintCompilation output
• 839033b: 8276976: Rename LIR_OprDesc to LIR_Opr
• 89b125f: 8275527: Refactor forward pointer access
• 36bd4a3: 8277404: Test VMDeprecatedOptions.java failing with Unable to create shared archive file
• 57eb864: 8276927: [PPC64] Port shenandoahgc to linux on ppc64le
• ... and 146 more: https://git.openjdk.java.net/jdk/compare/7320b77b3e451932ee8befa7af4b80593725761e...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

[mrserb]

As far as understand from the previous fix the "ignoreException" parameter does not suppress the currently raised exception, it just suppresses the warning in the XCheck:jni. So it will be good to propagate an exception to the user if this code is executed on the "java" thread, and log it by the trace macro if it is executed on a toolkit thread.

[prrace]

Yeah this looks like the wrong fix.
-Xcheck:jni only warns like this if there are actual exceptions, doesn't it ?
So if we had one, where was it ?

Note that Windows Server 2019 is a staple of the CI testing at Oracle and the test hasn't failed in the > 2 months since it was integrated, so I'm wondering why it fails in your case ?
Was this a debug build perhaps ?

[mrserb]

I think Xcheck:jni raises a warning when two JNI calls are made in a row w/o calling exception check in between. So it is not necessary to have an actual exception to produce a warning.

Probably it is reproduced there, because that system is "true" headless, and the execution code path is just different, or something like that, need to check what is the next/prev JNI call.
Or maybe this method really throw an exception, need some more detail.

[MBaesken]

Hello, in our central tests it was indeed a fastdbg OpenJDK. On my local Windows 10 machine I could not reproduce it.
Our central tests run with -Djava.awt.headless=true , but I think the Win2019 server machine itself is not headless .

[MBaesken]

I could add a J2dTraceLn(J2D_TRACE_ERROR, . . . ) in case an exception occurs. The J2dTraceLn is already used at some other places in DWMIsCompositionEnabled so it might fit better than just ignoring the exception.

[mrserb]

Before ignoring an exception it is better to check why the warning was raised, if that warning is correct then we should try to propogate/report exception to the app, if it is not possible then we should use trace macro.

[MBaesken]

Hello, I added a trace call. This is similar to what is done in https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/native/libawt/java2d/d3d/D3DRenderQueue.cpp#L869 .

[mrserb]

In the old fix the trace was added there because that method is executed in the infinite loop on some special thread, so an exception could not be thrown to the user, is it the case in the current issue?

[prrace]

We have issues running in debug mode even in headful mode - https://bugs.openjdk.java.net/browse/JDK-8264773
I think this PR should be withdrawn. We need a holistic look at making sure we run properly in debug builds on windows when we get time.
In other words don't try to fix up individual tests, especially by suppressing the error.

[MBaesken]

We have issues running in debug mode even in headful mode - https://bugs.openjdk.java.net/browse/JDK-8264773 I think this PR should be withdrawn. We need a holistic look at making sure we run properly in debug builds on windows when we get time. In other words don't try to fix up individual tests, especially by suppressing the error.

Hi Phil, what about excluding the test java/awt/font/JNICheck/FreeTypeScalerJNICheck.java on Windows ?
That would be fine with me too .

[RealCLanger]

We have issues running in debug mode even in headful mode - https://bugs.openjdk.java.net/browse/JDK-8264773 I think this PR should be withdrawn. We need a holistic look at making sure we run properly in debug builds on windows when we get time. In other words don't try to fix up individual tests, especially by suppressing the error.

Hi Phil, what about excluding the test java/awt/font/JNICheck/FreeTypeScalerJNICheck.java on Windows ? That would be fine with me too .

I understand that this is about the debug build on Windows only. So why not solve it like this: d042029 ?

[MBaesken]

Our central tests were running with a fastdebug jvm. I do not know what would have happened with an opt/product JVM on the same test machine. I would prefer the exclude list but if this is not wanted then we can use requires in the test as well.
The java/awt/font/JNICheck/FreeTypeScalerJNICheck.java test was added with Linux in mind anyway afaik.

[mrserb]

I understand that this is about the debug build on Windows only. So why not solve it like this: d042029 ?

The current issue does not produce any debug assertions nor try to open a debugger, so it is different. We need to check why the jni warning is produced, probably we call more java methods via jni in the debug build?

[MBaesken]

I looked a bit more into it; when connecting with Remote desktop connection to the Win Server 2019 test machine, I could run the jtreg test java/awt/font/JNICheck/FreeTypeScalerJNICheck.java on the command line successfully with BOTH the fastdebug and opt/product JVM.
The error occurs when starting the tests from the Windows Task scheduler; however when running from the task scheduler the error occurs with the fastdebug-JVM not when running the opt/product JVM.

[mrserb]

The error occurs when starting the tests from the Windows Task scheduler; however when running from the task scheduler the error occurs with the fastdebug-JVM not when running the opt/product JVM.

Probably in that case we try to log something and that logging include jni upcall?

[bridgekeeper]

@MBaesken This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

[prrace]

The error occurs when starting the tests from the Windows Task scheduler;
however when running from the task scheduler the error occurs with the fastdebug-JVM not
when running the opt/product JVM.

hmm. So the task scheduler may not have access to some desktop properties but I still don't see why debug vs product would be different. And the JNU_* function itself makes a sequence of calls without checking for exceptions.
clazz = (*env)->FindClass(env, class_name);
if (clazz == 0)
goto done2;
mid = (*env)->GetStaticMethodID(env, clazz, name, signature);
if (mid == 0)
goto done1;

The specs for these certainly say they may throw exceptions and
I'm very sure the VM doesn't know the code here does a check for ret == 0 so I'm puzzled why the JNU function isn't checking here ?

[bridgekeeper]

@MBaesken This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

[bridgekeeper]

@MBaesken This pull request has been inactive for more than 8 weeks and will now be automatically closed. If you would like to continue working on this pull request in the future, feel free to reopen it! This can be done using the /open pull request command.