[macOS/Cocoa] SIGSEGV in objc_release/objc_msgSend when closing an editor reactivates a PageBookView (Properties/Outline) whose Shell's native NSWindow is already gone

[laszloItemis]

Describe the bug

Repeatedly opening, closing, reopening, and closing editor tabs crashes the JVM with a native SIGSEGV inside libobjc.A.dylib (objc_release or objc_msgSend). Captured 10 crashes over 2 days of normal usage, all on the main SWT thread, all inside Display.readAndDispatch(), all si_code=2 (SEGV_ACCERR) with a different fault address each time.

To trigger: closing a part synchronously reactivates the next part in the editor/view stack, and that reactivation's toolbar relayout (PageBookView → ActionBars → ToolBarManager) touches a Shell whose native NSWindow has already been released as part of the very close operation that triggered it. Depending on heap state at the moment of the dangling access, this either:

• returns/dereferences nil safely, surfacing as a catchable NullPointerException that SafeRunner logs and swallows (non-fatal), or
• returns or releases a corrupted/dangling native pointer, crashing the JVM itself with SIGSEGV in the Cocoa Objective-C runtime (fatal).

Captured both the fatal and non-fatal variant of the exact same call path, so they probably share one root cause (more details below).

To Reproduce

I don't yet have an isolated standalone SWT snippet — only reproduced so far inside our full RCP product. Steps:

1. Start a workbench with a perspective that has a CTabFolder-based editor area plus a Properties/Outline view (PageBookView-based) that follows the active editor. Our case uses stacked diagram editors, each with its own Outline and Properties page.
2. Open several editors as tabs.
3. Close all of them.
4. Reopen several editors.
5. Close them again.

This has reproduced reliably.

Expected behavior

Closing/reopening editor tabs should never crash the JVM.

Screenshots

N/A — this is a native crash (JVM terminates), not a visual/rendering bug.

Environment:

1. Platform(s) on which the behavior is seen:

• All OS
• Windows
• Linux
• macOS

2. Additional OS info: macOS 26.5.2 (25F84), Darwin 25.5.0, arm64 (Apple Silicon, "Mac17,8", 18 cores / 48 GB). Only tested on macOS so far — unknown whether it reproduces on Windows/Linux.

3. JRE/JDK version: Temurin 21.0.11+10 (org.eclipse.justj.openjdk.hotspot.jre.full.macosx.aarch64_21.0.11.v20260515-1531)

Version since

Observed on SWT 3.134.0.v20260515-1429 (native libswt-pi-cocoa-4973r12.jnilib), Eclipse 2026-06 stream. As far as I am aware it was working fine with macOS 26.5.1 / Eclipse 2026-03.

Workaround (or) Additional context

No known workaround.

Path A — PageBookView / ToolBarManager reactivation on close (NSWindow.contentView())

Non-fatal variant (from the runtime workbench's .log, caught by SafeRunner) — entry point is StackRenderer.closePart:

!ENTRY org.eclipse.ui.workbench 4 2 2026-07-21 12:54:36.672
!MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.ui.workbench".
java.lang.NullPointerException: Cannot invoke "org.eclipse.swt.internal.cocoa.NSView.frame()" because the return value of "org.eclipse.swt.internal.cocoa.NSWindow.contentView()" is null
	at org.eclipse.swt.widgets.Shell.getClientArea(Shell.java:955)
	at org.eclipse.swt.widgets.Composite.minimumSize(Composite.java:920)
	at org.eclipse.swt.widgets.Composite.computeSize(Composite.java:238)
	at org.eclipse.swt.widgets.Shell.computeSize(Shell.java:623)
	at org.eclipse.swt.widgets.Control.pack(Control.java:2756)
	at org.eclipse.swt.widgets.Control.pack(Control.java:2730)
	at org.eclipse.jface.action.ToolBarManager.relayout(ToolBarManager.java:228)
	at org.eclipse.jface.action.ToolBarManager.update(ToolBarManager.java:394)
	at org.eclipse.ui.internal.e4.compatibility.ActionBars.updateActionBars(ActionBars.java:68)
	at org.eclipse.ui.part.PageBookView.showPageRec(PageBookView.java:929)
	at org.eclipse.ui.part.PageBookView.partActivated(PageBookView.java:698)
	at org.eclipse.ui.views.properties.PropertySheet.partActivated(PropertySheet.java:490)
	at org.eclipse.ui.part.PageBookView$1.partActivated(PageBookView.java:998)
	at org.eclipse.ui.internal.WorkbenchPage$3.run(WorkbenchPage.java:4900)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:47)
	at org.eclipse.ui.internal.WorkbenchPage.firePartActivated(WorkbenchPage.java:4897)
	at org.eclipse.ui.internal.WorkbenchPage$E4PartListener.partActivated(WorkbenchPage.java:216)
	at org.eclipse.e4.ui.internal.workbench.PartServiceImpl$2.run(PartServiceImpl.java:250)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:47)
	at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.firePartActivated(PartServiceImpl.java:247)
	at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.activate(PartServiceImpl.java:789)
	at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.activate(PartServiceImpl.java:695)
	at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.activate(PartServiceImpl.java:690)
	at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.hidePart(PartServiceImpl.java:1414)
	at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.hidePart(PartServiceImpl.java:1349)
	at org.eclipse.e4.ui.workbench.renderers.swt.StackRenderer.closePart(StackRenderer.java:1675)
	at org.eclipse.e4.ui.workbench.renderers.swt.StackRenderer.lambda$34(StackRenderer.java:1604)
	at org.eclipse.swt.events.SelectionListener$1.widgetSelected(SelectionListener.java:83)
	... (full trace in workspace-log-npe-excerpt.txt, attached)

Fatal variant of the exact same call path — SIGSEGV instead of a null return:

C  [libobjc.A.dylib+0x9820]  objc_msgSend+0x20
J  org.eclipse.swt.internal.cocoa.OS.objc_msgSend(JJ)J
J  org.eclipse.swt.internal.cocoa.NSWindow.contentView()Lorg/eclipse/swt/internal/cocoa/NSView;
j  org.eclipse.swt.widgets.Shell.getClientArea()Lorg/eclipse/swt/graphics/Rectangle;
j  org.eclipse.swt.widgets.Composite.minimumSize(IIZ)Lorg/eclipse/swt/graphics/Point;
J  org.eclipse.swt.widgets.Composite.computeSize(IIZ)Lorg/eclipse/swt/graphics/Point;
j  org.eclipse.swt.widgets.Shell.computeSize(IIZ)Lorg/eclipse/swt/graphics/Point;
J  org.eclipse.swt.widgets.Control.pack(Z)V
J  org.eclipse.swt.widgets.Control.pack()V
j  org.eclipse.jface.action.ToolBarManager.relayout(Lorg/eclipse/swt/widgets/ToolBar;II)V
J  org.eclipse.jface.action.ToolBarManager.update(Z)V
j  org.eclipse.ui.internal.e4.compatibility.ActionBars.updateActionBars()V
j  org.eclipse.ui.part.PageBookView.showPageRec(Lorg/eclipse/ui/part/PageBookView$PageRec;)V
j  org.eclipse.ui.part.PageBookView.partActivated(Lorg/eclipse/ui/IWorkbenchPart;)V

Path B — CTabFolder / StackRenderer async resize (NSWindow.windowNumber())

Non-fatal variant:

java.lang.NullPointerException: Cannot invoke "org.eclipse.swt.internal.cocoa.NSWindow.windowNumber()" because "window" is null
	at org.eclipse.swt.widgets.Control.internal_new_GC(Control.java:2138)
	at org.eclipse.swt.graphics.GC.<init>(GC.java:267)
	at org.eclipse.swt.graphics.GC.<init>(GC.java:228)
	at org.eclipse.swt.custom.CTabFolder.updateItems(CTabFolder.java:3838)
	at org.eclipse.swt.custom.CTabFolder.updateItems(CTabFolder.java:3834)
	at org.eclipse.swt.custom.CTabFolder.onResize(CTabFolder.java:2140)
	at org.eclipse.swt.custom.CTabFolder.lambda$0(CTabFolder.java:339)
	at org.eclipse.swt.widgets.Control.resized(Control.java:3380)
	at org.eclipse.swt.widgets.Composite.resized(Composite.java:1027)
	at org.eclipse.swt.widgets.Control.setFrameSize(Control.java:3971)
	at org.eclipse.swt.widgets.Display.windowProc(Display.java:6287)
	at org.eclipse.swt.internal.cocoa.OS.objc_msgSend(Native Method)
	at org.eclipse.swt.internal.cocoa.NSView.setFrameSize(NSView.java:260)
	at org.eclipse.swt.widgets.Control.setBounds(Control.java:3703)
	at org.eclipse.swt.widgets.Control.setSize(Control.java:4286)
	at org.eclipse.swt.widgets.Control.pack(Control.java:2756)
	at org.eclipse.swt.widgets.Control.pack(Control.java:2730)
	at org.eclipse.e4.ui.workbench.renderers.swt.StackRenderer.adjustTopRight(StackRenderer.java:1014)
	at org.eclipse.e4.ui.workbench.renderers.swt.StackRenderer.lambda$19(StackRenderer.java:628)
	at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:40)
	at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:132)
	at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4393)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:4016)
	... (full trace attached)

Most common crash:

C  [libobjc.A.dylib+0x8014]  objc_release+0x10
C  [libobjc.A.dylib+0xc130]  objc_autoreleasePoolPop+0xf4
C  [CoreFoundation+0x3c57c]  _CFAutoreleasePoolPop+0x20
C  [Foundation+0x1d3ac]  -[NSAutoreleasePool release]+0x8c
C  [libswt-pi-cocoa-4972r7.jnilib+0xe778]  Java_org_eclipse_swt_internal_cocoa_OS_objc_1msgSend__JJ+0x2c
J  org.eclipse.swt.internal.cocoa.OS.objc_msgSend(JJ)J
J  org.eclipse.swt.widgets.Display.readAndDispatch()Z
j  org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run()V
j  org.eclipse.core.databinding.observable.Realm.runWithDefault(...)V
j  org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(...)Ljava/lang/Object;
j  org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(...)V
... (full trace attached)

Both fatal crash variants land on the main SWT thread inside native Cocoa code reached via Display.readAndDispatch(), both have si_code=2 (SEGV_ACCERR) with a different fault address every time and both have a directly corresponding non-fatal NPE from the identical Java call path.

hs_err_pid91329.log.txt
workspace-log-npe-excerpt.txt