Was: MacOS 10.14.6 + OpenJDK11U 11.0.3.7 SIGSEGV on most AWT tests

AdoptOpenJDK: OpenJDK11U-jdk_x64_mac_hotspot_11.0.3_7.pkg

Does not occur with Java8.

+++

Now MacOS 10.14.6 + AdoptOpenJDK 11U Issues

Tested multiple AdoptOpenJDK builds, so far none was satisfactory,
see attachment.

Created attachment 820 [details]
AdoptOpenJDK OSX Issues 2019-08-23 (Tested a few builds)

The content of attachment 820 [details] has been deleted for the following reason:

to be replaced

Created attachment 821 [details]
AdoptOpenJDK OSX Issues 2019-08-23 (update)

Bottom line, we have to resolve the crash issue here.

Adding one more test .. 

jdk-12.0.2+10.2 - 6 August 2019
=================================================
openjdk version "12.0.2" 2019-07-16
OpenJDK Runtime Environment AdoptOpenJDK (build 12.0.2+10)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 12.0.2+10, mixed mode)

1) com.jogamp.opengl.test.junit.jogl.demos.gl2.awt.TestGearsAWT
java.lang.UnsatisfiedLinkError: /private/var/folders/m3/36qvs18n7vx5q33l3wc0slw80000gp/T/jogamp_0000/file_cache/jln17159475570397999035/jln14738818103097697267/natives/macosx-universal/libgluegen_rt.dylib: dlopen(/private/var/folders/m3/36qvs18n7vx5q33l3wc0slw80000gp/T/jogamp_0000/file_cache/jln17159475570397999035/jln14738818103097697267/natives/macosx-universal/libgluegen_rt.dylib, 1): no suitable image found.  Did find:
        /private/var/folders/m3/36qvs18n7vx5q33l3wc0slw80000gp/T/jogamp_0000/file_cache/jln17159475570397999035/jln14738818103097697267/natives/macosx-universal/libgluegen_rt.dylib: code signature in (/private/var/folders/m3/36qvs18n7vx5q33l3wc0slw80000gp/T/jogamp_0000/file_cache/jln17159475570397999035/jln14738818103097697267/natives/macosx-universal/libgluegen_rt.dylib) not valid for use in process using Library Validation: mapped file has no cdhash, completely unsigned? Code has to be at least ad-hoc signed.
        at java.base/java.lang.ClassLoader$NativeLibrary.load0(Native Method)
        at java.base/java.lang.ClassLoader$NativeLibrary.load(ClassLoader.java:2430)
        at java.base/java.lang.ClassLoader$NativeLibrary.loadLibrary(ClassLoader.java:2487)
        at java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2684)
        at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2617)
        at java.base/java.lang.Runtime.load0(Runtime.java:765)
        at java.base/java.lang.System.load(System.java:1866)
        at com.jogamp.common.jvm.JNILibLoaderBase.loadLibraryInternal(JNILibLoaderBase.java:604)
        at com.jogamp.common.jvm.JNILibLoaderBase.access$000(JNILibLoaderBase.java:64)
        at com.jogamp.common.jvm.JNILibLoaderBase$DefaultAction.loadLibrary(JNILibLoaderBase.java:107)
        at com.jogamp.common.jvm.JNILibLoaderBase.loadLibrary(JNILibLoaderBase.java:488)
        at com.jogamp.common.os.DynamicLibraryBundle$GlueJNILibLoader.loadLibrary(DynamicLibraryBundle.java:427)
        at com.jogamp.common.os.Platform$1.run(Platform.java:321)

(Same as: jdk-11.0.4+11.2 - 6 August 2019 jdk-11.0.4+11.2)

openjdk13-ea-20190809-build33
=================================================
openjdk version "13" 2019-09-17
OpenJDK Runtime Environment (build 13+33)
OpenJDK 64-Bit Server VM (build 13+33, mixed mode, sharing)

(same as w/ jdk-11.0.4+11)
^^^ Only due to ssh remote access!
If accessing locally, same crash Bug 1389: Demo runs, but crashes at tearing down the test!

Created attachment 822 [details]
hs_err_pid10557.log crash report  w/ OpenJDK Runtime Environment (11.0.3+7)

This crash occurs not with Java8.
On Java11 (diverse versions) the crash occurs.

Reason is that the NSOpenGLLayer detachment command 
at MacOSXCGLContext's drawable disassociation won't get passed 
through the 'macos main thread'.

MacOSXCGLContext's drawable disassociation runnable is send to the main thread
via performSelectorOnMainThread:@selector(jRun) in native code.
Thereafter we even try to kick the NSApp thread via an empty message.

However, the runnable is never executed and the NSOpenGLLayer still attached,
to the CALayer which probably causes the issue at hand.

Further investigation ..

(In reply to Sven Gothel from comment #9)
> This crash occurs not with Java8.
> On Java11 (diverse versions) the crash occurs.
> 
> Reason is that the NSOpenGLLayer detachment command 
> at MacOSXCGLContext's drawable disassociation won't get passed 
> through the 'macos main thread'.
> 
> MacOSXCGLContext's drawable disassociation runnable is send to the main
> thread
> via performSelectorOnMainThread:@selector(jRun) in native code.
> Thereafter we even try to kick the NSApp thread via an empty message.
> 
> However, the runnable is never executed and the NSOpenGLLayer still attached,
> to the CALayer which probably causes the issue at hand.
> 
> Further investigation ..

In case we simply issue the disassociation action on the current thread from MacOSXCFLContext (caller), no crash.

Reason we used to delegate the CALayer action to the main thread 
is macos's own policy .. well. 

Need to figure out why the task won't get executed on main thread.

Culprit of the crash and the non propagated action on NSApp main-thread 
was _simply_ our OSXUtil_KickNSApp() 'kick alive' 
NSApplicationDefined NSEvent sent to the NSApp.

Java11's NSApp code overrides sendEvent and handles
  NSApplicationDefined + subtype=ExecuteBlockEvent
using the given data1 as a function pointer. 8-O

ExecuteBlockEvent defined as 0, which we have sent.

Simply passing subtype=8888 avoids this side-effect.
Whether it is still required to KickNSApp() is another question.

+++

Further, make code a bit more robuts regarding the offscreenSurfaceLayer
at JAWTWindow invalidate. I.e. if still not detached, do the late cleanup there.
This just in case the OSX Context callback to disassociate the drawable 
has been missed.

fixed by commit 534d764474cacf8bc380123cbfd164c7c55f236a

+++

sneaked in commit db843e65c6b93d720438c7e751413c0556f51a6e

OSXUtil::IsMainThread() Utilize ThreadLocal storage flag avoiding unnecessary JNI calls