[dfattal]

Fixes #1947.

Root cause

The crash is not an AppKit race. It is one CGL context in use on two threads at once.

• cube_handle_gl_macos renders with [g_glView openGLContext] and passes g_glView through XR_DXR_cocoa_window_binding.
• For an NSOpenGLView, comp_gl_window_macos_setup_external adopted the view's existing openGLContext. That is the same context the app renders with, so the compositor had no private context.
• The Decouple weave rate from app render rate: re-weave the last atlas at panel rate with fresh eye positions #868 repaint thread makes that context current and replays the weave on it (gl_crop_and_process_dp → glBlitFramebuffer). It is serialised against the app only by c->mutex and app_frame_in_progress, and both cover xrEndFrame alone. The app's own GL (RenderScene, between xrBeginFrame and xrEndFrame) runs outside both.
• The result is that one GLDContextRec is driven from two threads. The crash reports show the faulting repaint thread in GLRResourceList::addResource while, at the same moment, the main thread is in RenderScene → GLDContextRec::flushContext. When the main thread loses the race instead, it aborts with Metal validation in glDrawElements.

Hiding the OS cursor was only a timing trigger: it shifts the app's frame cadence just enough for the repaint gate to open. With DXR_WEAVE_REPAINT_FORCE=1 (a repaint every refresh), the old code crashes 10/10 launches with the cursor extension OFF.

The adapter in displayxr-common is not involved: NSCursor hide/unhide already runs on the main thread. So there is no displayxr-common PR.

Fix

• No repaint on an app-owned context. No lock the runtime takes can cover the app's own GL calls, so the GL compositor does not start the repaint thread when its context is the app's own. comp_gl_window_macos_context_is_app_owned() reports that case, and a one-time WARN says so: #868/#1947: weave repaint OFF — …. The app's frames weave and present exactly as before. The only loss is the between-frames replay for this one configuration (an app that binds an NSOpenGLView).
• Private contexts keep the repaint. These are the own-window, plain-NSView and offscreen-texture paths. The macOS repaint arm now also takes CGLLockContext, the lock AppKit takes around -[NSOpenGLContext update] on the main thread.
• cube_handle_gl_macos: depth cursor default-on again. The feat(cursor): the runtime draws the depth cursor — Vulkan + GL (ADR-046 Amendment 2 §B) #1946 opt-in is undone; DISPLAYXR_CURSOR_DEPTH=0 opts out, the same as the Metal and Vulkan cubes. The issue reference is removed from the app.
• ADR-046. The "known issue" bullet is rewritten as the resolved root cause.

Evidence

All runs are on this Mac (M-series), sim-display, SIM_DISPLAY_OUTPUT=sbs, 10 s per launch. An early exit counts as a crash. Each crash left a .ips report.

configuration	before (repaint on the app context)	after
cursor active, runtime draws (DISPLAYXR_CURSOR_DEPTH_UV=0.5,0.5)	1 / 15 (SIGSEGV in repaint thread), then 0 / 30	0 / 32
same, DXR_WEAVE_REPAINT_FORCE=1	10 / 10	0 / 10
extension off (DISPLAYXR_CURSOR_DEPTH=0), DXR_WEAVE_REPAINT_FORCE=1	10 / 10	0 / 10
app draws the crosshair (DISPLAYXR_CURSOR_DEPTH_DRAW=app)	—	0 / 10
custom sprite (DISPLAYXR_CURSOR_DEPTH_SPRITE=custom)	—	0 / 6
cursor never active (UV 0.1,0.1)	—	0 / 8
extension off	—	0 / 8
cube_hosted_legacy_gl (private context, repaint still ON)	—	0 / 8; with FORCE 0 / 6, repaints firing (count=273)

Notes on the evidence:

• How "before" was measured. For the forced and 30-run columns, the same build had the new gate bypassed by a temporary env check that is not committed.
• Crash signatures across the 20 forced before-crashes:
  • 16 × SIGSEGV on gl_repaint_thread in GLRResourceList hash emplace, the same as the issue's stack 1.
  • 3 × the same fault reached from RenderScene.
  • 1 × SIGABRT.
• Unforced rate. Without FORCE, the repaint gate opened in only 1 of the 30 before-runs. That is why the natural rate is low and timing-dependent.
• The cursor still draws. The GL atlas capture after the fix shows the runtime-drawn arrow on the cube in both tiles, with disparity.

Not tested

• A real Leia/vendor panel on macOS GL. There is no macOS GL weaver here besides sim-display.
• The NSOpenGLView + DXR_WEAVE_REPAINT loss in practice: a stalled GL handle app now holds its last presented frame instead of re-weaving. sim-display has no tracked phase, so this cannot be seen here.
• The Windows / Linux GL paths. They are unchanged (the code is __APPLE__-only) and were not run.
• The plain-NSView external path (private context attached to the app's view) under the new CGL lock. No test app takes it.

🤖 Generated with Claude Code