Open jzy3d opened 1 year ago
Hi folks, I have persistent issues in gephi with Mac OS hangs and I'm wondering why that might be the case for us but not for Sweet Home 3D or other JOGL applications. I'm using the same JOGL versions (rc-4 + this 20221118 hotfix). In any event, as the root cause is unknown this is, and probably will continue to be a big issue.
The hang always happen in a similar stacktrace than involve RunOnMainThread
. The originating call might not always be the same but the most common seems to be at initialization CreateNSWindow
.
"AWT-EventQueue-0" #23 prio=6 os_prio=31 cpu=957.36ms elapsed=53.53s tid=0x0000000130cc7000 nid=0x11503 in Object.wait() [0x000000029c068000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(java.base@11.0.17/Native Method)
- waiting on <no object reference available>
at java.lang.Object.wait(java.base@11.0.17/Unknown Source)
at jogamp.nativewindow.macosx.OSXUtil.RunOnMainThread(OSXUtil.java:318)
- waiting to re-lock in wait() <0x00000003fe38d638> (a java.lang.Object)
at jogamp.nativewindow.macosx.OSXUtil.CreateNSWindow(OSXUtil.java:161)
at jogamp.nativewindow.jawt.macosx.MacOSXJAWTWindow.lockSurfaceImpl(MacOSXJAWTWindow.java:319)
at com.jogamp.nativewindow.awt.JAWTWindow.lockSurface(JAWTWindow.java:677)
at com.jogamp.opengl.awt.GLCanvas.createJAWTDrawableAndContext(GLCanvas.java:718)
at com.jogamp.opengl.awt.GLCanvas.addNotify(GLCanvas.java:621)
Hi @mbastian
By reading the Gephi discussion I understand that
the MacOSXCGLContext
patch suggested by Emmanuel does not consider version 12 has a target for changing the blocking condition of OSXUtil
, neither checks if CPU is M1 or Intel. Not clear to me but maybe we are in un uncovered case.
Do not forget that Emmanuel encountered such hang when a Java application is ran concurrently with other natives applications (see discussion above).
The RunOnMainThread
method discussed above has an additional flag named kickNSApp
that I presume would try to kick a native application already using the macOS main thread. It would be worth investigating the effect of changing it.
using this OSXUtil
method in PanamaGL as well, I’ll try to dig in the reasons for deadlock (which also occur when I keep the wait
to true on 10.15+Intel - without using any other class of JOGL.
This would be helpful to discuss this issue with Apple developers to verify what may be wrong with the RunOnMainThread
approach.
Thanks @jzy3d for the additional context. As you may have read it on the thread, I've had this questionnaire to users about this hang issue :) Although this is based on the 0.9.7 version, which is prior to my fix attempt it showed me that it's encountered in the wild by various Mac OS versions. See below the results (N=16):
I also know that most users experience it at startup. I've never been able to reproduce this situation myself. I only got it to hang when switching perspective in Gephi, which is equivalent to hide and the re-show the GLCanvas.
Correct me if I'm wrong, but I though Emmanuel's patch was purely focused on the release
call. Here it's like the same hang but happening on other calls like CreateNSWindow
. It's still possible that these are completely separated issue but it's suspicious enough to me. In any event, the patch from Emmanuel wouldn't help at this point.
Do not forget that Emmanuel encountered such hang when a Java application is ran concurrently with other natives applications (see discussion above).
The RunOnMainThread method discussed above has an additional flag named kickNSApp that I presume would try to kick a native application already using the macOS main thread. It would be worth investigating the effect of changing it.
Ok I think I've somehow missed that. I'll look into that more closely in my debugging.
That's great to have such statistics!
Correct me if I'm wrong, but I though Emmanuel's patch was purely focused on the release call. Here it's like the same hang but happening on other calls like CreateNSWindow. It's still possible that these are completely separated issue but it's suspicious enough to me. In any event, the patch from Emmanuel wouldn't help at this point.
Yes, you are right.
CreateNSWindow
, which is invoked here.It is worth knowing OSXmisc, the macos native source code file backing OSXUtil.java. Maybe from there we can identify AppKit functions and read their doc to verify if they're properly used.
I notified Emmanuel about this discussion, he will probably have good advices.
Hi @mbastian ,
Here is an idea : the common point between init and deletion of the context is the use of RunOnMainThread
. Both cases are initially triggered with the wait
flag to true
, meaning both method will block until the main macOS thread achieves the tasks.
What you could try would be to apply here the patch that Emmanuel applied here, where the patch is as follow (nb : I send the location of Emmanuel patch but none of us actually commited the change here)
String osVersion = System.getProperty("os.version");
boolean wait = osVersion.startsWith("10.")
&& !osVersion.startsWith("10.14")
&& !osVersion.startsWith("10.15")
&& !osVersion.startsWith("10.16");
OSXUtil.RunOnMainThread(wait /* wait */, true /* kickNSApp */, new Runnable() {
@Override
public void run() {
[...]
} } );
The hard point then becomes to customize JOGL without rebuilding everything. Let me know if you can achieve this!
Hi @mbastian ,
Another thought about this problem : in JOGL, OSXUtil
allows dispatching OpenGL queries to the macOS main thread. This avoid the software user to run his program with -XStartOnMainThread
option.
Since CreateNSWindow
method also make use OSXUtil.RunOnMainThread
, we can assume that the thread dispatch may be a culprit and try to avoid such dispatch that causes trouble to Emmanuel.
For Gephi user experiencing a hang, I would try to run with the VM arg -XStartOnMainThread
on macOS. In this case, the app will be initialized on macOS main thread, and the OSXUtil.RunOnMainThread
method will simply execute tasks without invoking suspicious objective-C API.
Thanks @jzy3d, for now I haven't been looking at changing JOGL code but rather see if I'm doing something special/wrong or find a workaround. It's still an option but higher effort as I would need to get familiar with that process, which doesn't look easy. Obviously if everything else fails I would need to get started on that :)
For Gephi user experiencing a hang, I would try to run with the VM arg -XStartOnMainThread on macOS. In this case, the app will be initialized on macOS main thread, and the OSXUtil.RunOnMainThread method will simply execute tasks without invoking suspicious objective-C API.
I did found this as well and tried it but in that case my application didn't even boot so I abandoned. But I can try again. I thought this was reserved for SWT apps but I'm Swing / Netbeans Platform.
@mbastian I am sorry, the exact VM arg is -XstartOnFirstThread
, but you probably found it?
@mbastian I am sorry, the exact VM arg is
-XstartOnFirstThread
, but you probably found it?
Yes, that's what I'm using. I do find reports on the web that Swing + this VM arg isn't working but I'm digging deeper.
After giving a try on a panama stub, I also notice that this arg makes swing hang. Removing SwingUtilities.invokeLater helps going further when this arg is here but did not completely solved the non displayed window.
After giving a try on a panama stub, I also notice that this arg makes swing hang. Removing SwingUtilities.invokeLater helps going further when this arg is here but did not completely solved the non displayed window.
Yes, I gave up after reading a bit and seeing that this isn't gonna work with my full Swing application. I searched Netbeans repo for this parameter and found zero hits, which probably means it's a stupid thing to do...
EDIT: Found this:
Initially discussed here by Manu
Problem
Solution
Next