macOS Golden Gate 27.0 Context menu becomes orphaned (window stops receiving input) or crashes in -[BSSimpleAssertion dealloc]

Start by tracing SWT’s Cocoa context-menu path from the reported native call OS.objc_msgSend into the menu popup implementation; the issue identifies libswt-pi-cocoa-4974r10.jnilib and NSMenu/AppKit but names no source file or test. Review the attached hang and crash evidence and reproduce with the overflowing Project Explorer menu and cascading Team submenu on macOS 27.0. Done means identifying a reliable SWT-side cause or reproducer for the hang/crash; the issue does not specify a fix or test.

Environment

• macOS 27.0 (26A428), MacBook Air M5 (Mac17,4), built-in 13" display, no external monitor
• Eclipse IDE for Enterprise Java (epp.package.jee) 4.41.0.20260903-0719, aarch64
• SWT native libs: libswt-pi-cocoa-4974r10
• JRE: bundled JustJ OpenJDK 25.0.4
• SVN team provider: Subclipse 4.3.4.202306191346 org.tigris.subversion.subclipse.feature.group Subclipse

Summary

Since upgrading to macOS 27.0, showing context menus in Eclipse intermittently fails in one of two ways:

1. Hang (several times a day): the context menu stays drawn on screen after it should close, and the Eclipse window stops responding to mouse and keyboard input. Esc, Tab, Ctrl+Tab and switching to another app do not dismiss it. The orphaned menu stays visible on top of other apps. The only recovery is killing Eclipse.
2. Crash (3 times in 6 days, Sep 21, 23 and 26): EXC_BREAKPOINT (SIGTRAP) in -[BSSimpleAssertion dealloc], called from AppKit's context-menu presentation.

Both began immediately after the macOS 27.0 upgrade. Neither occurred on the previous macOS version with the same Eclipse setup.

Steps to reproduce (intermittent)

1. In Project Explorer, right-click a project. On this display the context menu is taller than the screen, so AppKit shows a scroll arrow.
2. Hover over Team to open the cascading submenu.
3. Select an item, or dismiss the menu.

Some fraction of the time, the menu (root plus the Team submenu) remains on screen and Eclipse stops receiving input. [State whether you have seen this with short menus, e.g. in the editor, or only with the long Project Explorer menu.]

Evidence: hang

A thread dump (jcmd) and a 10 s native sample (sample) taken during a hang show the UI thread idle in the event loop, not blocked:

"main" #3 prio=6 ... runnable
   java.lang.Thread.State: RUNNABLE
        at org.eclipse.swt.internal.cocoa.OS.objc_msgSend_bool(Native Method)
        at org.eclipse.swt.internal.cocoa.NSRunLoop.runMode(NSRunLoop.java:40)
        at org.eclipse.swt.widgets.Display.sleep(Display.java:5214)
        at org.eclipse.ui.application.WorkbenchAdvisor.eventLoopIdle(WorkbenchAdvisor.java:339)
        ...

5926 Thread_1537849   DispatchQueue_1: com.apple.main-thread  (serial)
+ 5926 Java_org_eclipse_swt_internal_cocoa_OS_objc_1msgSend_1bool__JJJJ  (libswt-pi-cocoa-4974r10.jnilib)
+   5926 -[NSRunLoop(NSRunLoop) runMode:beforeDate:]  (Foundation)
+     5926 __CFRunLoopRun  (CoreFoundation)
+       5926 __CFRunLoopServiceMachPort  (CoreFoundation)
+         5926 mach_msg2_trap  (libsystem_kernel.dylib)

All 5926 samples are in mach_msg2_trap, and there are no BLOCKED threads. Eclipse is waiting for events that never arrive, which suggests the menu-tracking session was never torn down and input is still routed to the orphaned menu. A screenshot of the orphaned menu over another app is attached.

Evidence: crash

All three crash reports have the same signature and the same instruction offset (...b74):

Exception Type:    EXC_BREAKPOINT (SIGTRAP)
esr: 0xf2000000 (Breakpoint) brk 0

Thread 0 Crashed::  Dispatch queue: com.apple.main-thread
0  BaseBoard   -[BSSimpleAssertion dealloc] + 556
1  AppKit      +[NSContextMenuImpl presentPopup:fromView:withContext:animated:async:completionBlock:] + 2684
2  AppKit      _NSPopUpMenu + 1992
3  AppKit      -[NSCocoaMenuImpl _popUpContextMenu:withEvent:forView:withFont:async:completionBlock:] + 328
4  AppKit      -[NSMenu _popUpContextMenu:withEvent:forView:withFont:async:completionBlock:] + 384
5  libswt-pi-cocoa-4974r10.jnilib  Java_org_eclipse_swt_internal_cocoa_OS_objc_1msgSend__JJJJJ + 68

The trap looks like BaseBoard's check for an assertion released without being invalidated. My guess is that the hang and the crash are two outcomes of the same menu-lifecycle problem in AppKit on macOS 27: the teardown either traps or never runs.

Possibly relevant

• The root context menu overflows the screen and scrolls, and the failure involves a cascading submenu.
• Accessibility bundles (AppKit.axbundle, WritingTools.axbundle, etc.) are loaded in the process. [List any apps with Accessibility permission, or say "none known."]
• I don't know whether SWT's synchronous popUpContextMenu path differs from what AppKit expects on 27.0. I'm also filing Apple Feedback: [FB24957365].

Attachments

• 3 crash reports (.ips)
• jcmd thread dump and sample output captured during a hang
• Screenshot of the orphaned menu