JOGL 2.4rc4 + JDK Temurin 17.02+8 + SWT 4.23 + macOS + ARM Processor = Crash w/o exception

[AlexisDrogoul]

Hi,

I've tried a rather adventurous combination (which is the one we are currently supporting for GAMA -- https://github.com/gama-platform/gama) and it crashed, which is disappointing, especially because I am unable to determine what makes it crash.

The goal was to go "all native": the JDK is native, Eclipse is the native aarch64 version (and SWT is a native binary), and I used the JOGL version (2.4rc4) that contains the native ARM libraries for macOS. GAMA is run from Eclipse, in a configuration that works well on Intel computers or with Rosetta.

Everything is running fine (Java2D displays, SWT views, etc.) except JOGL, which crashes without warnings as soon as one tries to open a NEWT Window (used for the OpenGL displays in GAMA).

Here are the two "logs" I was able to gather.. Any ideas welcome !

The log produced by JOGL: https://gist.github.com/AlexisDrogoul/1adb8dd5a80602ae0f6b5691796c0532#file-log

The crash report produced by Apple: https://gist.github.com/AlexisDrogoul/1adb8dd5a80602ae0f6b5691796c0532#file-crash

[AlexisDrogoul]

Just to mention that the use of the SWT GLCanvas provided by JOGL crashes too, but the view appears briefly (and seems valid) before it crashes.

[AlexisDrogoul]

I had little hope, but who knows ? I have also tested the combination with Azul Zulu and Oracle JDKs -- but the same crash happens. .

[jzy3d]

Hi @AlexisDrogoul,
I'll look at the stack you shared and will try to depict. What is the main contextual difference with this issue that you commented some time ago? Did you just choose a more recent JDK and more recent SWT?
The versions I was referring to in my crash are SWT 3.* and JDK 11.

[AlexisDrogoul]

Thanks :) -- and yes, everything changed except JOGL :)

SWT is the version indicated here (https://forum.jogamp.org/JOGL-incompatible-with-SWT-4-21-td4041643.html) as having fixed a bug on Linux. It is actually not already out (I've been working on the RC2a version) but will be soon.

The JDKs (Temurin, Zulu and Oracle) are all version 17.02+8, necessary in our case to have Java2D displays, that rely on AWT_SWT, to work correctly on macOS...

And finally, I used a M1 MacMini (last time was on Intel). Everything working just fine under Rosetta. And I can tell that the AArch64 library is indeed found and loaded because, sometimes, the display appears very briefly and disappears almost immediately.

[jzy3d]

From reading your logs it seams that you are using rc-20210111 instead of rc-4 (or maybe what I did while mangling rc-20210111 to create rc-4 did not yield to an accurate version log).

While testing on many platforms I noticed that using a non-ARM JDK (hence a JDK made for Intel) on an ARM based Apple M1 will enable Rosetta and hence will make use of JOGL natives made for Intel, which make rc-20210111 working.

My first assumption is that you are still using rc-20210111 and not rc4.

Are you able to verify which JOGL version stand in your java classpath? The -XshowSettings:properties JVM Option can print the exact list of jar files in your classpath.

[AlexisDrogoul]

Thanks for the feedback. 🤔 I'm a bit lost now. Are there binaries I can download of 2.4rc4 that include the M1 natives ?

[AlexisDrogoul]

I have actually downloaded and used the binaries found here: https://download.jzy3d.org/jogl/. Is there another place I can download 2.4rc4 from ?

[AlexisDrogoul]

Unfortunately, it seems that the version returned by the jars is not the correct one... Version 2.4rc4 from Maven returns rc-20210111 ...

[jzy3d]

Sorry for this bad direction. It may be due to the fact that the rc4 is made of jars where the native part made for ARM is appended to the existing rc-2021011. So not a complete rebuilt (which is tedious).

The single other way to get RC4 is to do it through Maven but I think you are not using it in your application since you chose to download the zip archive.

[jzy3d]

Just and idea as these log files remain a bit mysterious to me : there is a sentence mentioning that the application must be started from the main thread. OpenGL being single threaded, I had to add a specific JVM flag on macOS on another OpenGL based projects which was -XstartOnFirstThread.

This would be relevant with the fact that the crash occurs out of the main thread while trying to update the OpenGL context - see also this.

The last point related to GL context is that one of the latest info before JOGL stops emitting logs is mentioning an update of the OpenGL context.

[AlexisDrogoul]

Thanks Martin ! Good try. However, XstartOnFirstThread is one of the first arguments you learn to use when developing RCP apps on macOS. So it is passed to the JVM all right. Since your comments, I've tried two different animators (one very simple, only one thread, the other a bit more sophisticated, but they both fail). Maybe I can try to come up with a very simple implementation of the GLAnimatorControl interface to see if that changes anything.

[jzy3d]

Another idea : is it normal to have this animator working in thread 68 and not in the first one ?