8269223: -Xcheck:jni WARNINGs working with fonts on Linux#4572
8269223: -Xcheck:jni WARNINGs working with fonts on Linux#4572mkartashev wants to merge 6 commits intoopenjdk:masterfrom
Conversation
|
👋 Welcome back mkartashev! A progress list of the required criteria for merging this PR into |
|
@mkartashev The following label will be automatically applied to this pull request:
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. |
Webrevs
|
| /* @test | ||
| * @bug 8269223 | ||
| * @summary Verifies that -Xcheck:jni issues no warnings from freetypeScaler.c | ||
| * @requires os.family == "linux" |
There was a problem hiding this comment.
Can we run this test on all platforms? Since this bug was not found, means we did not cover this code by the tests, and it will be useful to test it even if the code path will be different on other platforms.
There was a problem hiding this comment.
Sure; dropped the @requires clause.
| FTScalerInfo* scalerInfo) { | ||
| freeNativeResources(env, scalerInfo); | ||
| (*env)->CallVoidMethod(env, scaler, invalidateScalerMID); | ||
| // NB: Exceptions must not be cleared (and therefore no JNI calls performed) after calling this method |
There was a problem hiding this comment.
Please split long lines to 80 chars per line
| sunFontIDs.ttReadBlockMID, | ||
| bBuffer, offset, numBytes); | ||
| // This is a callback, we are not returning immediately to Java and better report exceptions now | ||
| CHECK_EXCEPTION(env); |
There was a problem hiding this comment.
Probably we should report it only if "debugFonts" was set?
| if ((*(env))->ExceptionCheck(env)) { \ | ||
| (*(env))->ExceptionDescribe(env);\ | ||
| (*(env))->ExceptionClear(env); \ | ||
| } |
There was a problem hiding this comment.
https://docs.oracle.com/en/java/javase/11/docs/specs/jni/functions.html#exceptiondescribe
"The pending exception is cleared as a side-effect of calling this function"
So you certainly don't need both of these and I would prefer that Describe only be used if really debugging where we think there's a REAL chance of an exception rather than just to keep JNI happy.
And the upcall that is likely (readBlock) itself will log any IOException (and catch it) in the event of an I/O error so I really think this is unlikely to be useful here.
There was a problem hiding this comment.
Yes, makes sense. I made CHECK_EXCEPTION() call either Clear... or Describe... based on the value of debugFonts.
Please, take a look.
| scalerInfo->font2D, | ||
| sunFontIDs.ttReadBlockMID, | ||
| bBuffer, offset, numBytes); | ||
| // This is a callback, we are not returning immediately to Java and better report exceptions now |
There was a problem hiding this comment.
I think the comment is un-needed .. since the only reason to call CHECK_EXCEPTION() is because of this.
Same for the other case.
There was a problem hiding this comment.
OK, comments removed.
1. Allowed test to run on any platform. 2. Trimmed comments to fit in with 80 columns. 3. Removed unnecessayr comments. 4. Made the ExceptionDescribe() calls conditional on the value of FontUtilities.debugFonts()
|
Looks fine to me, I'll run the tests. |
@mrserb Any news on that front? |
The new test fails on all platforms:
|
system. 2. Added exception checks to Windows-specific code.
| J2dTraceLn(J2D_TRACE_VERBOSE, " executing runnable"); | ||
| JNU_CallMethodByName(env, NULL, pFlush->runnable, "run", "()V"); | ||
| jboolean ignoreException; | ||
| JNU_CallMethodByName(env, &ignoreException, pFlush->runnable, "run", "()V"); |
There was a problem hiding this comment.
What is the purpose of this change? the only difference is that in the second case the ExceptionCheck will be called, does it affect something?
There was a problem hiding this comment.
Yes, the ExceptionCheck() call will silence the warnings from -Xcheck:jni.
There was a problem hiding this comment.
Does it actually suppress the "Xcheck:jni" or it clears a raised exception? If an exception is still "raised" after this call we should do some additional steps to log/clean it.
There was a problem hiding this comment.
Yes, the exception will still be "raised" after this call. Since there are no JNI calls (at least those that are forbidden to make with an exception pending) between here and return back to Java, I believe no additional steps are necessary.
There was a problem hiding this comment.
Then I suggest logging them via some of the trace macros.
There was a problem hiding this comment.
Sure, added some logging.
| jboolean ignoreException; | ||
| jintArray obj = (jintArray)JNU_CallStaticMethodByName(env, &ignoreException, | ||
| "java/awt/event/InputEvent", | ||
| "getButtonDownMasks", "()[I").l; |
There was a problem hiding this comment.
obj might be null? Can not we just add CHECK_NULL(obj) here?
There was a problem hiding this comment.
obj indeed might be null, especially since all kinds of things could go wrong during class/method resolution. Added CHECK_NULL(obj) here.
1. Added CHECK_NULL() to awt_Component.cpp
|
Ping. |
|
I'm going to see if the test passes on the internal systems we use which I think will be mostly variout RH/OL systems for this headless test for Linux - and it also will get run on Windows Server of some kind .. I don't think macOS will hit this code path at all for this test. |
| import java.awt.*; | ||
| import java.awt.geom.Rectangle2D; | ||
| import java.awt.image.*; | ||
| import java.io.*; |
There was a problem hiding this comment.
Can we get rid of all these wild card imports ?
There was a problem hiding this comment.
Sure, replaced with single-class imports.
| * @bug 8269223 | ||
| * @summary Verifies that -Xcheck:jni issues no warnings from freetypeScaler.c | ||
| * @library /test/lib | ||
| * @key headful |
There was a problem hiding this comment.
What about this test is headful ?
There was a problem hiding this comment.
oh you are getting metrics for a JFrame ? That's not going to exercise any new font code so is pointless except to make it so the test has to be headful.
There was a problem hiding this comment.
But getFontMetrics() is the primary "entry point" that generated all the JNI warnings in the first place. And I'm also not sure that we could've gotten all the warnings on Windows without JFrame.
There was a problem hiding this comment.
So what's wrong with
g2d.setFont(font);
FontMetrics metrics = g2d.getFontMetrics(font);
?
No frame needed.
There was a problem hiding this comment.
Indeed. Changed the test per your suggestions.
|
|
||
| for (String ff : families) | ||
| { | ||
| Font font = Font.decode(ff); |
There was a problem hiding this comment.
Gosh, does anyone still use decode() ? I keep forgetting it exists.
You have all the family names, why not just new Font(ff, Font.PLAIN, 12) ?
There was a problem hiding this comment.
OK, changed to new Font(...).
1. Optimized imports in the test. 2. Got rid of Font.decode().
Looks good. I tried the test as headless and headful which happens to then exercise a broader set of distros than only one or the other the way our systems are set up. |
|
@mkartashev 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: 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 739 new commits pushed to the
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. As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@prrace, @mrserb) but any other Committer may sponsor as well. ➡️ To flag this PR as ready for integration with the above commit message, type |
1. Added code to log the exception if it occurred when running a flushBuffer's runnable. The logging is minimal in order to avoid replacing the exception with another one before it reaches Java. 2. Made the test not dependent on headful code as per @prrace suggestions.
|
Will the updated test case cover the same code paths where the bugs were found and fixed by this change? |
I believe so - on Linux. Windows-specific changes are mostly covered (I verified |
|
/integrate |
|
@mkartashev |
|
/sponsor |
|
Going to push as commit 9bc0232.
Your commit was automatically rebased without conflicts. |
|
@mrserb @mkartashev Pushed as commit 9bc0232. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
Added an
ExceptionCheck()followed byExceptionDescribe()andExceptionClear()immediately after the Java calls made from the callback functionReadTTFontFileFunc()infreetypeScaler.c.The exception(s) need to be cleared because we're not returning immediately to Java that would've been able to handle them gracefully. And in order not to loose the exception entirely (even though the return value would also indicate an error condition), print out the exception with
ExceptionDescribe()to aid in debugging.Progress
Issue
Reviewers
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/4572/head:pull/4572$ git checkout pull/4572Update a local copy of the PR:
$ git checkout pull/4572$ git pull https://git.openjdk.java.net/jdk pull/4572/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 4572View PR using the GUI difftool:
$ git pr show -t 4572Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/4572.diff