Dear All,
With JDK 25 to be released, I've been testing it on MacOS for our molecular simulation software Force Field X (https://ffx.biochem.uiowa.edu). It runs as expected with JDK 24, but with JDK 25 there's the following error: Main Thread Checker: UI API called on a background thread: -[NSWindow contentView] PID: 29225, TID: 39822572, Thread name: Java: AWT-EventQueue-0, Queue name: com.apple.root.default-qos.overcommit, QoS: 0 Backtrace: 4 libnativewindow_macosx.dylib 0x0000000386368b78 Java_jogamp_nativewindow_macosx_OSXUtil_GetNSView0 + 72 Further details using the JOGL logging flags: Platform: MACOS / Mac OS X 15.6 (15.6.0), aarch64 (ARM64, EABI_AARCH64), 12 cores, littleEndian true MachineDataInfo: runtimeValidated true, 32Bit false, primitive size / alignment: ----------------------------------------------------------------------------------------------------- Package: com.jogamp Implementation Version: 2.5.0 Implementation Build: 2.5-b967-20230818 Implementation Branch: origin/master Implementation Commit: a235ae5dae463afa16f62f48bf62f896efa80b68 Any thoughts on this issue? I tried to submit to BugZilla, but I'm not sure if special permissions are needed? To replicate the error, you can install the software using the instructions here: https://ffx.biochem.uiowa.edu/download.html Thanks, - Mike |
Administrator
|
Interesting, looks like GetNSView0 violated main-thread constraints (thread checker).
I forgot, we do enable it (optional?) or have you enabled the checker? So on same machine, it works w/ JDK24 but not JDK25. This implies that JDK25 AWT (?) uses a different thread. Are you willing to put all infos w/ complete backtrace and toolkit (AWT or ..) to a new bugreport you create? If so, I can use this email address and add you to our bugzilla. |
Yes - on the same machine our program runs as expected with JDK 24, but then fails with latest JDK 25 release candidate build.
The stack trace was generated using the following suggested flags I found on the JogAmp Wiki: -Djnlp.newt.debug=all -Djnlp.nativewindow.debug=all -Djnlp.jogl.debug=all Otherwise I didn't do anything (that I know of?) to enable the thread checker. I have the full logging prepared using these flags for both JDK 24 and JDK 25. I'm happy to create a bug report once I can login to Bugzilla. Thanks, - Mike |
Administrator
|
Excellent, thx!
I have created a bugzilla account, you should have received an email. Please perform a 'password reset' :) Thank you, perhaps we can squeeze that in for 2.6.0 |
Administrator
|
https://jogamp.org/bugzilla//show_bug.cgi?id=1528#c2
resolved, please see details. Good news, JDK 25 has been validated to work (Linux, MaxOS) and all but one GetNSView() calls moved to the main-thread for 'cosmetic reasons' today. (future behavior may change, so it was a good deed) |
Great - thanks Sven!
Does the August 22nd RC include the fix? https://jogamp.org/deployment/v2.6.0-rc-20250822/ |
Administrator
|
Nope, the next one - which might be final soon if I hear no complaints.
|
Using the latest build (2.6.0-rc-20250827), I encounter a different error on JDK 25:
AWT-EventQueue-0 - Info: NativeWindowFactory.<init>: Type .macosx custom / .macosx native Threading: jogl.1thread null, singleThreaded false, hasAWT false, mode MT, plugin null GLProfile.initSingleton() - thread AWT-EventQueue-0 [2]: com.jogamp.opengl.GLProfile.initSingleton(GLProfile.java:213) [3]: com.jogamp.opengl.GLProfile.getProfileMap(GLProfile.java:2395) [4]: com.jogamp.opengl.GLProfile.get(GLProfile.java:1039) [5]: com.jogamp.opengl.GLProfile.get(GLProfile.java:1068) [6]: com.jogamp.opengl.GLProfile.getMaxFixedFunc(GLProfile.java:821) [7]: org.jogamp.java3d.JoglPipeline.initialize(JoglPipeline.java:149) [8]: org.jogamp.java3d.Pipeline.createPipeline(Pipeline.java:101) [9]: org.jogamp.java3d.MasterControl.loadLibraries(MasterControl.java:888) [10]: org.jogamp.java3d.VirtualUniverse.<clinit>(VirtualUniverse.java:266) [11]: org.jogamp.java3d.SceneGraphObject.setDefaultReadCapabilities(SceneGraphObject.java:136) [12]: org.jogamp.java3d.PointAttributes.<init>(PointAttributes.java:98) Any thoughts? The same Force Field X build runs as expected with JDK 24. |
Administrator
|
First, the earlier observation wasn't an error, but informative as I have described
in Bug 1528 here <https://jogamp.org/bugzilla//show_bug.cgi?id=1528#c1>. (Only visible if the debug property is enabled) Now the GLProfile.initSingleton is also no error, just an reporting when it gets initialized for debuging purposed (when debug is enabled). So, no bug at all. You have not answered my earlier question in the bug report whether you app is working, which I assume it is. At least these informative traces are no errors! EDIT: Please turn off debug flags and see what JogAmp is still showing on stderr. |
Hi Sven,
My apologies for not answering your earlier question. The logging without debug flags is: WARNING: A terminally deprecated method in sun.misc.Unsafe has been called WARNING: sun.misc.Unsafe::objectFieldOffset has been called by com.jogamp.common.util.UnsafeUtil$1 (file:/Users/mjschnie/Data/ffx-project/forcefieldx/lib/jogamp-fat-2.6.0.jar) WARNING: Please consider reporting this to the maintainers of class com.jogamp.common.util.UnsafeUtil$1 WARNING: sun.misc.Unsafe::objectFieldOffset will be removed in a future release Trace/BPT trap: 5 After the "Trace/BPT trap: 5" message the program crashes. Should I upload the full logging to the bug report? Thanks!, - Mike |
Administrator
|
Re "Trace/BPT trap: 5"
is this happening with - a: v2.6.0-rc-20250822 - b: v2.6.0-rc-20250827 - c: debug-on - d: debug-off Since this is the first time I hear about the SIGTRAP 5 (MacOS aarch64), I would assume it only happens now w/ (b) + (d)? (but this could be a wrong assumptions) I searched for this SIGTRAP 5 and surprise surprise it happened quite often but developer didn't find documentation on it (from Apple). Please give me a matrix where SIGTRAP 5 happens on your MacOS aarch64 + JDK25, as it doesn't happen on amd64 or aarch64+JDK24? Full logs (debug on/off w/ and w/o crash appreciated). Also the MacOS Crash-Reporter logs w/ the actual native backtrace would be very helpful. The previous JogAmp verbose logs w/ debug enabled were probably misleading (?) PS: Yes, it is often hard to find the culprit, hence all info is important. Now I will copy this over to our bug-report and it would be great if we can continue from there. <https://jogamp.org/bugzilla//show_bug.cgi?id=1528> Thank you. |
Hi Sven,
This is just a quick note to confirm the fix in the 2.6.0 release works great in my hands for our Force Field X program on JDK 21, 24 & 25 on MacOS. Thank you! |
Administrator
|
Excellent. Good that you have found and reported the issue. Thank you.
|
Free forum by Nabble | Edit this page |