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 ?

[AlexisDrogoul]

The first one is reserved by SWT if I'm not wrong. I wouldn't take the risk of slowing the animation when moving the mouse ^^. And in any case we can have several animators running in parallel in GAMA, something that works very well under Rosetta, so we can't really restrict ourselves to one thread.

[AlexisDrogoul]

I was wondering if you were following this thread : processing/processing4#370

They seem to have made interesting progress (w/o SWT though)

[jzy3d]

The fix has been proposed here https://github.com/jzy3d/jogl/pulls, I just forgot it :/

[Bio7]

Hello Alexis,

I had a similar crash which I described here:

https://forum.jogamp.org/JOGL-2-4-and-Java-17-report-td4041572.html

The crash occured when opening the newt window (or resizing the window - after deactivating the animator, etc.)

Your error message is similar to what I sometimes got (running on wrong thread)

The crash was caused by the FPSAnimator class which I use for a dynamic content with constant framerate. I simply copied the class (similar of what you did with gtk) and wrapped the called display method (called in the run method of the class):

https://github.com/Bio7/bio7/blob/master/com.eco.bio7/src/com/eco/bio7/spatial/FPSAnimator.java#L205

[AlexisDrogoul]

Hi ! Thanks a lot ! I will try when I'm back to office and tell you if it works.
Of course, what worries me here is that if it is the only fix, it kind of competes with the whole architecture we have in place... Syncing on the SWT main thread means that either the rendering will capture all inputs and prevent regular user interaction with the rest of the UI or will be severely affected whenever the user will interact with this UI. Do you have this issue as well on Bio7 ?
In any case, thanks again for this little light of hope :)

[AlexisDrogoul]

@jzy3d I wonder if this PR might solve the issue described here, as it explicitly revolves around updating the GL context in the main thread ... Any chance you'd do a new build anytime soon ^^ ?

[AlexisDrogoul]

@Bio7 Your workaround produced something ! Not exactly what was expected, a different behavior. The crash is gone, which is undoubtedly a progress. But the display does not display anything (just a grey surface, which I suspect is not even a Newt Window, just the empty Composite supposed to host it, but I haven't had time to debug) Thanks anyway, I feel we are in the right direction !

[AlexisDrogoul]

@Bio7 @jzy3d Forget the previous comment. It is working. I had the leftovers of various attempts in my code, which prevented the display to open. Things are working very well, even with several OpenGL displays. A bit of a lag because of the sharing of the thread with SWT UI, but it is already something !! Thanks a lot both of you !!

[Bio7]

Great to hear. I see no performance issues using only one view (or a split of the same view).

Hopefully the jogl development continues so that we don't need all these workarounds.

It would be nice to see soon a final 2.4 release.

[jzy3d]

Great there is a fix on this topic.

I however fear I can't copy paste this fix as is in FPSAnimator. I fear some applications not using SWT (and not having SWT in classpath would fail using FPSAnimator since your fix makes FPSAnimator dependent on org.eclipse.ui.PlatformUI).

[Bio7]

Yes, this was a fix for a RCP. However, for SWT a Display display =Display.getDefault().... would also work.

For JavaFX Platform.runLater could work, too if there is an error. Same for Swing. Not tested though.

SWT could be detected. A short search on the internet gave me some maybe usable templates:

https://git.dorkbox.com/dorkbox/Utilities/src/commit/d58812acafdcc00eab0ba0b1649bf18624d82578/src/dorkbox/util/Swt.java#L45

[AlexisDrogoul]

@jzy3d yes, clearly. But, as @Bio7 says, we could probably imagine a class that would provide the "relevant main thread" depending on the detection of the windowing system used by the GLAutoDrawable(s) animated by the animator. A best guess of course. And to ease the development of custom animators, one could also extract the call to display() in a separate method in the GLAnimatorControl hierarchy, so as to redefine it more simply.