Bug 1528

(In reply to Michael Schnieders from comment #0)
"with the JDK 25 the following error is produced: Main Thread Checker: UI API called on a background thread: -[NSWindow contentView]"

The 'Main Thread Checker' is enabled on MacOS by JOGL by setting properties
- `nativewindow.debug.OSXUtil.MainThreadChecker`, or
- `nativewindow.debug=all`

"Main Thread Checker—This tool verifies that system APIs that must run on the main thread actually do run on that thread."

See 
- jogl commit 7e76df3a05b7eb2404cb4584ee0b34ea287eb9bf.
- <https://developer.apple.com/documentation/xcode/diagnosing-memory-thread-and-crash-issues-early>
- dead link <https://developer.apple.com/documentation/code_diagnostics/main_thread_checker?language=objc>

The checker is IMHO only reporting (potential) issues, but the application should function as expected.

Of course, it seems that JDK 24/25 differences observed
- JDK 24 called a method via the main-thread, not AWT EDT (?)
- JDK 24 had another 'realize' order, i.e. instantiation of actual native resources

Reason for not moving all little queries on the main-thread is performance,
i.e. unwilling to flip-flop and block UI.

+++

I will re-test this behavior w/ JDK 25.

+++

Question: Does your application work as expected w/ JDK 25 or is it behaving erroneous?

The issue of OSXUtil.GetNSView() not on main-thread is observable to me on JDK 21, 24 and 25 simply calling `com.jogamp.opengl.test.junit.jogl.demos.es2.awt.TestGearsES2AWT`.

It is regularly called from OSXDummyUpstreamSurfaceHook.create()
and certain other functions.

To mitigate a potential future issue (today w/ JDK 25 it works well, despite the Main-Thread-Checker notice), I have done the following non-intrusive change:

commit 05bcb255ca909eb3a3a1f5df1b82b5b58ddad06e

    Bug 1528: Mitigate OSXUtil.GetNSView() performed on non main-thread
    
    When running with `Main Thread Checker`, enabled by system property
    - `nativewindow.debug.OSXUtil.MainThreadChecker`, or
    - `nativewindow.debug=all`
    OSXUtil.GetNSView() gets notices as it is not forcefully performed on the main-thread.
    
    This change adds an option to GetNSView 'onMainThread'.
    
    On use cases where CreateNSWindow is performed on main-thread anyways,
    we utilize CreateNSWindow2, which returns the tuple win and view handle.
    
    Only in one instance we intentionally leave GetNSView performed
    on the current thread, MacOSXCGLContext.NSViewDescriptor ctor.
    The latter is called from MacOSXCGLContext.NSOpenGLImpl.create
    and MacOSXCGLContext.NSOpenGLImpl.makeCurrent and could cause deadlock issues.
    
    Hence this change soothes the debugging experience
    and resolves potential future issues in all but one spot.

Michael, in case the single left GetNSView() call causes an actual 
error with your application (unlikely), please reopen and notify me explicitly.

Thank you.

Michael replied <https://forum.jogamp.org/JOGL-on-MacOS-with-JDK-25-tp4043869p4043892.html>:

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

(In reply to Sven Gothel from comment #4)
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.

Thank you.

Created attachment 896 [details]
Jogl 2.6.0-rc-20250827 using JDK25 on MacOS 15.6 aarch64

Jogl debug logging (-Dnewt.debug=all -Dnativewindow.debug=all -Djogl.debug=all) until: 
Trace/BPT trap: 5

The same result occurs without debug logging (Trace/BPT trap: 5).

Created attachment 897 [details]
MacOS crash report for 2.6.0-rc-20250827 on MacOS 15.6 with JDK 25

The same behavior is seen with 2.6.0-rc-20250822 for JDK 25. No problems with JDK 24.

Hi Sven,

The "Trace/BPT trap: 5" happens with both v2.6.0-rc-20250822 and v2.6.0-rc-20250827 with debug on or off (all 4 cases crash on JDK 25).

> Please give me a matrix where SIGTRAP 5 happens on your MacOS aarch64 + JDK25, as it doesn't happen on amd64 or aarch64+JDK24?

I don't have an amd64 machine -- only aarch64. All 2.5.0 JOGL releases and the 2.6.0-rc work fine with in my hands on aarch64 with JDK 24, while all JOGL builds crash on JDK 25 on MacOS.

> Also the MacOS Crash-Reporter logs w/ the actual native backtrace would be very helpful.

I've uploaded the debug logging for v2.6.0-rc-20250827 on JDK 25 prior to the Trace/BPT trap: 5, and also the MacOS crash report.

I hope these help!

Created attachment 898 [details]
MacOS Problem Report

The stack trace is easier for me to follow in this version. Here's the trace for the thread that crashed (all info is in the log):

Thread 34 Crashed:: Java: AWT-EventQueue-0
0   AppKit                        	       0x192847cc0 -[NSWMWindowCoordinator performTransactionUsingBlock:] + 752
1   AppKit                        	       0x1926ee238 _NSWMTransactionAddOrderingActionWithInfoForOptions + 184
2   AppKit                        	       0x1926ed4ac _NSWMOrderWindow + 588
3   AppKit                        	       0x191d7a818 _NSOrderWindow + 360
4   AppKit                        	       0x192668d78 -[NSWindow _orderOut:calculatingKeyWithOptions:documentWindow:] + 1320
5   AppKit                        	       0x191b6b000 NSPerformVisuallyAtomicChange + 108
6   AppKit                        	       0x19266a430 -[NSWindow _reallyDoOrderWindowOutRelativeTo:] + 496
7   AppKit                        	       0x19266a794 -[NSWindow _reallyDoOrderWindow:] + 80
8   AppKit                        	       0x19266a9e4 -[NSWindow _doOrderWindow:] + 264
9   AppKit                        	       0x192664c84 -[NSWindow _finishClosingWindow] + 444
10  AppKit                        	       0x191daacc8 -[NSWindow _close] + 380
11  libnativewindow_macosx.dylib  	       0x384890ac4 Java_jogamp_nativewindow_macosx_OSXUtil_DestroyNSWindow0 + 88

(In reply to Michael Schnieders from comment #9)

Thank you. Now we have some clarity!

Our native method `Java_jogamp_nativewindow_macosx_OSXUtil_DestroyNSWindow0`
crashes on `Thread 34 Crashed:: Java: AWT-EventQueue-0`.

The crash seems to be triggered on aarch64 w/ JDK25 only,
implying that JDK25 offloads the task on that AWT thread - or similar.

The `SIGNAL, Code 5 Trace/BPT trap: 5` seems to triggered by
some sanity check on aarch64 only I assume.

This is something I can work with.

jogl commit f5964604d3e940c07c3e6af884f06b4eceb08dd4

Bug 1528: Perform all `OSXUtil.DestroyNSWindow()` calls on AppKit's MainThread
OSXDummyUpstreamSurfaceHook::destroy() was using current thread, moved to appkit main-thread.

Tested with `com.jogamp.opengl.test.junit.jogl.demos.es2.awt.TestGearsES2AWT`,
i.e. reproduced crash pre-patch and resolved thereafter.

Please reopen if persisting.

Additional remark:
[1] full unit test on macosx aarch 64 JDK 21
[2] full unit test on macosx aarch 64 JDK 24
[3] full unit test on macosx aarch 64 JDK 25

No difference in results, just 4 failures - mostly due to missing NEWT/AWT key translation. Hence this seems working well no.

Thanks 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.