8259343: [macOS] Update JNI error handling in Cocoa code. #1967

prrace · 2021-01-06T21:14:06Z

Proposed updates to JNI error handling.

Progress

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

Issue

JDK-8259343: [macOS] Update JNI error handling in Cocoa code.

Reviewers

Erik Joelsson (@erikj79 - Reviewer)
Sergey Bylokhov (@mrserb - Reviewer)

Download

$ git fetch https://git.openjdk.java.net/jdk pull/1967/head:pull/1967
$ git checkout pull/1967

bridgekeeper · 2021-01-06T21:14:55Z

👋 Welcome back prr! 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 · 2021-01-06T21:16:14Z

@prrace The following labels will be automatically applied to this pull request:

2d
awt
build

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

mrserb · 2021-01-07T00:35:27Z

src/java.desktop/macosx/native/libosxapp/JNIUtilities.h

+ * or maybe a way for the app to continue running depending on the exact
+ * nature of the problem that has been detected and how survivable it is.
+ */
 #define CHECK_EXCEPTION() \


Since this macro does not try to return from the outer code we can change it to the method?

But then "env" would need to be passed explicitly. I don't think the churn is worth it.
And a method would then need a .m or .c file ...

But that could be merged to the CallXXXMethod and placed somewhere in the libosxapp

You mean those methods or macros that we already discussed and I explained why I do not want to do that ?
This is a small update for error checking not revisiting everything done before.

mrserb · 2021-01-07T00:38:28Z

src/java.desktop/macosx/native/libosxapp/JNIUtilities.h

 #define CHECK_EXCEPTION() \
    if ((*env)->ExceptionOccurred(env) != NULL) { \
-        (*env)->ExceptionClear(env); \
+        if ([NSThread isMainThread] == YES) { \


Isn't it is a similar code to the

jdk/src/java.desktop/macosx/native/libosxapp/NSApplicationAWT.m

Line 334 in 67c2211

[app run];

Where we just catch an exception log it, and continue to run our infinite loop? Why do we need to do something specific here? I mean we cannot drop any try/catch blocks anyway since an nsexception may be generated by some external system code.

In my testing that code does not get called. The new code does. So the old code could probably be deleted as useless but it is also harmless and just maybe it'll catch something else, even if it isn't doing anything that I can see.

That code for sure should be called, it is even improved recently by JDK-8255681
I'll check how it was intended to work.

I hadn't noticed that line - and definintely not realised it was recent.
I suppose he must have had a way to trigger it.
But I don't think it hurts to have both.

I just tried to understand why we need to complicate this, to me, it is unclear why handling the same errors in the NSApplicationAWT.m does not work.

Because of the reason I've said before. That logging in NSApplication AWT is not being seen. Something is swallowing it. So I'd say if anything remove that logging and keep the new one but as I also said it isn't harmful to have provision in case it also logs some case we aren't catching.

mrserb · 2021-01-07T00:40:49Z

src/java.desktop/macosx/native/libosxapp/JNIUtilities.h

       NSLog(@"Bad JNI lookup %s\n", name); \
+       NSLog(@"%@",[NSThread callStackSymbols]); \
+       if ([NSThread isMainThread] == NO) { \
+           JNU_ThrowInternalError(env, "Bad JNI Lookup"); \


It will be possible that(most of the time) the JNU_ThrowInternalError will be called while we already have a raised java exception.

I don't think "most" of the time is very likely. JNI lookup failures don't cause exceptions to be thrown.
Is that what you are tihinking ?

And separately, with either the current code of clearing exceptions or the change here to the practice of throwing NSException on seeing a Java Exception I think it very unlikely.

Then how we get NoSuchMethodError here? https://bugs.openjdk.java.net/browse/JDK-8259232?
https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#GetMethodID
Calling Instance Methods: GetMethodID
RETURNS:
Returns a method ID, or NULL if the specified method cannot be found.
THROWS:
NoSuchMethodError: if the specified method cannot be found.
ExceptionInInitializerError: if the class initializer fails due to an exception.
OutOfMemoryError: if the system runs out of memory.

Same for fields:
https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#GetFieldID

Ok. I will only create my own if none is pending.

prrace · 2021-01-08T19:05:09Z

src/java.desktop/macosx/native/libosxapp/JNIUtilities.h

+           } else { \
+              if ((*env)->ExceptionOccurred(env) != NULL) { \
+                  (*env)->ExceptionDescribe(env); \
+              } \


So the update here is that if we are not on the appkit thread, make sure a java exception is thrown.
If we are on the appkit thread, clear any java exception since it isn't going anywhere but do it using
describe which prints it.

I read the logic of the method differently, probably the wrong indents?

If we are not on the toolkit thread then

Check ExceptionOccurred -> throw JNU_ThrowInternalError if needed or check exception again ->call ExceptionDescribe

NSException raise at the end.

I have a paren in the wrong place ! I've pushed an update.

mlbridge · 2021-01-09T01:33:01Z

Webrevs

mrserb · 2021-01-11T05:52:02Z

src/java.desktop/macosx/native/libosxapp/JNIUtilities.h

       NSLog(@"Bad JNI lookup %s\n", name); \
+       NSLog(@"%@",[NSThread callStackSymbols]); \
+       if ([NSThread isMainThread] == NO) { \
+           if ((*env)->ExceptionOccurred(env) == NULL) { \


Not sure that the check for ExceptionOccurred is needed, in all other places where we check the ref to methods/field we only check the return value, and if it is null then return immediately assuming that an exception is rased already, for example :

jdk/src/java.desktop/windows/native/libawt/windows/awt_Button.cpp

Line 357 in b72de3c

cls = env->FindClass("java/awt/Button");

Note that the exception in the static initializer is fatal for the application.

Not sure that the check for ExceptionOccurred is needed,
It may not be needed in practice but if the code path is never taken no harm ...

in all other places where we check the ref to methods/field we only check the return value, and if it is null then return immediately assuming that an exception is rased already, for example :

jdk/src/java.desktop/windows/native/libawt/windows/awt_Button.cpp

Line 357 in b72de3c

cls = env->FindClass("java/awt/Button");

Note that the exception in the static initializer is fatal for the application.

Nothing new here.

The new thing here is that you check the result of the ExceptionOccurred if NULL is returned from the GetMethodID/etc, we usually never do it. If such checks are necessary then I'll create a separate bug to update other similar use cases.

Here I don't have immediate control over why this is being called.
So we could have null but no pending exception depending on what the caller did.
It won't be executed except in the rare case there's a problem so it certainly isn't causing overhead so what is the problem ?
I don't see a need to change other code unless there's a really good reason.

mrserb · 2021-01-11T05:58:28Z

src/java.desktop/macosx/native/libosxapp/JNIUtilities.h

+           } else { \
+              if ((*env)->ExceptionOccurred(env) != NULL) { \
+                  (*env)->ExceptionDescribe(env); \
+              } \


I read the logic of the method differently, probably the wrong indents?

If we are not on the toolkit thread then

Check ExceptionOccurred -> throw JNU_ThrowInternalError if needed or check exception again ->call ExceptionDescribe

NSException raise at the end.

mrserb · 2021-01-11T06:01:36Z

src/java.desktop/macosx/native/libosxapp/JNIUtilities.h

 #define CHECK_EXCEPTION() \
    if ((*env)->ExceptionOccurred(env) != NULL) { \
-        (*env)->ExceptionClear(env); \
+        if ([NSThread isMainThread] == YES) { \


I just tried to understand why we need to complicate this, to me, it is unclear why handling the same errors in the NSApplicationAWT.m does not work.

erikj79 · 2021-01-11T18:56:38Z

make/modules/java.desktop/Lib.gmk

      LDFLAGS := $(LDFLAGS_JDKLIB) \
          $(call SET_SHARED_LIBRARY_ORIGIN), \
      LIBS := \
+          -ljava \


There should be a dependency declaration added too. Something like this right after the SetupJdkLibrary macro call:

$(BUILD_LIBOSXAPP): $(call FindLib, java.base, java)

There should be a dependency declaration added too. Something like this right after the SetupJdkLibrary macro call:

$(BUILD_LIBOSXAPP): $(call FindLib, java.base, java)

Fixed.

erikj79

Build changes look good.

openjdk · 2021-01-11T20:21:12Z

@prrace 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:

8259343: [macOS] Update JNI error handling in Cocoa code.

Reviewed-by: erikj, serb

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 108 new commits pushed to the master branch:

c338f11: 8259349: -XX:AvgMonitorsPerThreadEstimate=1 does not work right
ccac7aa: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp
4c75d14: 8259374: Make ThreadInVMfromNative have ResetNoHandleMark
563b268: 8257709: C1: Double assignment in InstructionPrinter::print_stack
400dc76: 8252015: [macos11] java.awt.TrayIcon requires updates for template images
ac2dee5: 8259539: JDK-8255711 broke trap messages
4697cfa: 8259576: Misplaced curly brace in Matcher::find_shared_post_visit
a6ab9e4: 8258576: Try to get zerobased CCS if heap is above 32 and CDS is disabled
a3561ae: 8258243: C2: assert failed ("Bad derived pointer") with -XX:+VerifyRegisterAllocator
4663704: 8259583: Remove unused decode_env::_codeBuffer
... and 98 more: https://git.openjdk.java.net/jdk/compare/80544e4d5f402f67171eb5aca11897f1c5c3d431...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 · 2021-01-12T02:31:56Z

src/java.desktop/macosx/native/libosxapp/JNIUtilities.h

+              } \
+         }  \
+        if (getenv("JNU_NO_COCOA_EXCEPTION") == NULL) { \
+            [NSException raise:NSGenericException format:@"Java Exception"]; \


How did you check that the logging in the NSApplication was swallowing? Both macro will throw the NSException on the toolkit thread now, does it mean that in both cases the logging in the NSApplication will be ignored/no output?

See the bug assigned to you that I filed last month : https://bugs.openjdk.java.net/browse/JDK-8258797
This error should have been logged by that NSApplicationAWT code but was not (and I mean in JDK 16 as well before I started on this) and in JDK 17 it was seen only when adding the new logging.

I have found it down to the absence of NSApplication#reportException() method and logging in it. Ok will update that code later in the separate update.

prrace · 2021-01-12T20:18:52Z

/integrate

openjdk · 2021-01-12T20:20:14Z

@prrace Since your change was applied there have been 108 commits pushed to the master branch:

c338f11: 8259349: -XX:AvgMonitorsPerThreadEstimate=1 does not work right
ccac7aa: 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp
4c75d14: 8259374: Make ThreadInVMfromNative have ResetNoHandleMark
563b268: 8257709: C1: Double assignment in InstructionPrinter::print_stack
400dc76: 8252015: [macos11] java.awt.TrayIcon requires updates for template images
ac2dee5: 8259539: JDK-8255711 broke trap messages
4697cfa: 8259576: Misplaced curly brace in Matcher::find_shared_post_visit
a6ab9e4: 8258576: Try to get zerobased CCS if heap is above 32 and CDS is disabled
a3561ae: 8258243: C2: assert failed ("Bad derived pointer") with -XX:+VerifyRegisterAllocator
4663704: 8259583: Remove unused decode_env::_codeBuffer
... and 98 more: https://git.openjdk.java.net/jdk/compare/80544e4d5f402f67171eb5aca11897f1c5c3d431...master

Your commit was automatically rebased without conflicts.

Pushed as commit d6a2105.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

8259343: [macOS] Update JNI error handling in Cocoa code.

e12b60a

openjdk bot added 2d client-libs-dev@openjdk.org build build-dev@openjdk.org awt client-libs-dev@openjdk.org labels Jan 6, 2021

mrserb reviewed Jan 7, 2021

View reviewed changes

8259343: [macOS] Update JNI error handling in Cocoa code.

0e745aa

prrace commented Jan 8, 2021

View reviewed changes

prrace marked this pull request as ready for review January 9, 2021 01:29

openjdk bot added the rfr Pull request is ready for review label Jan 9, 2021

mrserb reviewed Jan 11, 2021

View reviewed changes

8259343: [macOS] Update JNI error handling in Cocoa code.

08a4115

erikj79 reviewed Jan 11, 2021

View reviewed changes

8259343: [macOS] Update JNI error handling in Cocoa code.

913b37c

erikj79 approved these changes Jan 11, 2021

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Jan 11, 2021

mrserb reviewed Jan 12, 2021

View reviewed changes

mrserb approved these changes Jan 12, 2021

View reviewed changes

openjdk bot closed this Jan 12, 2021

openjdk bot added integrated Pull request has been integrated and removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Jan 12, 2021

prrace deleted the jnf_update branch February 10, 2021 19:37

8259343: [macOS] Update JNI error handling in Cocoa code. #1967

8259343: [macOS] Update JNI error handling in Cocoa code. #1967

Uh oh!

Conversation

prrace commented Jan 6, 2021 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Issue

Reviewers

Download

Uh oh!

bridgekeeper bot commented Jan 6, 2021

Uh oh!

openjdk bot commented Jan 6, 2021

Uh oh!

Choose a reason for hiding this comment

Uh oh!

prrace Jan 8, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mlbridge bot commented Jan 9, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Webrevs

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

erikj79 left a comment

Choose a reason for hiding this comment

Uh oh!

openjdk bot commented Jan 11, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

prrace commented Jan 6, 2021 •

edited by openjdk bot

Loading

prrace Jan 8, 2021 •

edited

Loading

mlbridge bot commented Jan 9, 2021 •

edited

Loading

openjdk bot commented Jan 11, 2021 •

edited

Loading