LIke I said in the bug report, if we get OOME here then we'll get more
from the following calls and if we want to make this accessibility code
robust
against this theoretical problem a massive destabilising re-write is needed.
How about this change instead
---
a/src/java.desktop/macosx/native/libawt_lwawt/awt/JavaComponentAccessibility.m
+++
b/src/java.desktop/macosx/native/libawt_lwawt/awt/JavaComponentAccessibility.m
@@ -136,7 +136,7 @@
fJavaRole = [javaRole retain];
fAccessible = (*env)->NewWeakGlobalRef(env, accessible);
-
+ (*env)->ExceptionClear(env); // in case of OOME
jobject jcomponent = [(AWTView *)fView awtComponent:env];
fComponent = (*env)->NewWeakGlobalRef(env, jcomponent);
(*env)->DeleteLocalRef(env, jcomponent);
-----
ExceptionClear is harmless if there is no exception pending.
And we will be "using jni correctly" in making the next call to
NewWeakGlobalRef
.. .even if it fails.
fAccessible is mostly guarded against use of NULL so it might even make
things better
but definitely won't harm anything.
If we ever see a real issue here that de-stabilising re-write will be
needed.
But not in JDK 9.
Its either make the mostly useless small change or "will not fix" but
we are supposed to be fixing these JNI correctness bugs.
-phil.
On 1/16/17, 7:17 AM, Sergey Bylokhov wrote:
Hi, Phi.
// these constants are duplicated in CAccessibility.java
@@ -136,7 +137,7 @@
fJavaRole = [javaRole retain];
I am not sure but it seems strange that we will return the "self"(and will use
it later), because it is not nil and was not properly initialized (for example
fActionsLOCK field which is used for synchronization will be nil).
