[Bug]: macOS main-process crash in accessibility line-range handling (SIGTRAP) #17476

Before submitting

• I searched existing issues and did not find a matching report. [Bug]: macOS renderer grows to ~4 GB RSS over a long multi-thread session, then crashes with EXC_BREAKPOINT (SIGTRAP) in node::Environment::allocate_managed_buffer #17295 (renderer memory growth) and [Bug]: Desktop main process SIGTRAPs during preview_open webview attach / debugger.attach #8332 (preview debugger attachment) have different process/function signatures.
• I included native crash evidence, matching symbolication, register/disassembly proof, and focused OS-log correlation sufficient to investigate. A deterministic reproduction is not yet available.

Area

apps/desktop — macOS main process / Chromium accessibility

Steps to reproduce / observed circumstances

1. Run T3 Code Nightly 0.0.46-nightly.20261009.2861 on Apple silicon macOS.
2. Use the app normally with many agents working. The observed session had been open for approximately 5 hours.
3. The entire desktop app unexpectedly terminates.

This is an observed incident, not a deterministic repro. No special action was identified by the user. There is no evidence that dictation, manually enabling an accessibility feature, or a specific agent action was required. The active app was not deliberately crashed again during investigation.

The native stack and OS logs narrow the trigger: macOS was requesting AXTextMarkerRangeForLine from T3. Apple's AXVisualSupportAgent logged that same request against the crashed main-process PID at the crash boundary. This is the most concrete starting point for a repro.

Expected behavior

An accessibility query for a line's text range should return a valid range or fail safely if its line/text position is no longer valid. It must not terminate the main application process.

Actual behavior

The main process executes a native bounds-assertion trap while handling the accessibility request:

EXC_BREAKPOINT (SIGTRAP)
Termination: SIGNAL 5, Trace/BPT trap
Crashed thread: 0, CrBrowserMain / com.apple.main-thread

Matching official Electron symbols resolve the failure to gfx::IsValidCodePointIndex, called from Chromium accessibility position normalization. At the trap, the requested UTF-16 index is 2975, while the string-view length is 0.

Impact

Occasional failure with full application termination; the user must relaunch. Frequency and task-loss/recovery behavior have not been established. This report does not claim that agent workload itself caused the crash.

Version or commit

• T3 Code Nightly: 0.0.46-nightly.20261009.2861.
• Release tag maps to commit 3b6af0b.
• Electron Framework: 44.4.5.
• Chromium pin in Electron's DEPS: 152.0.7977.130.

Environment

• macOS 26.6.2 (25G83).
• Apple M4, ARM64, hardware model Mac16,12, 16 GB RAM.
• Incident: 2026-10-09 15:39:38.3527 +0400.
• Main process PID 10656; renderer PID 10723.
• Application launched at 10:38:20.2614 +0400.

Logs or stack traces

Correctly symbolicated native path

The crash report, installed framework, and official Electron 44.4.5 ARM64 symbols all have framework UUID 4C4C44ED-5555-3144-A1CB-427AA45E6F33.

macOS _AXXMIGCopyParameterizedAttributeValue / CopyParameterizedAttributeValue
  -[BrowserAccessibilityCocoa accessibilityAttributeValue:forParameter:]
    AXTextMarkerRangeForLine
    ui::AXPosition<...>::CreatePreviousLineStartPosition
      ui::AXPosition<...>::CreateBoundaryStartPosition
        ui::AXPosition<...>::AsLeafTextPositionBeforeCharacter
          gfx::IsValidCodePointIndex(std::u16string_view, size_t)
            libc++ bounds assertion -> brk #1

Framework-relative offsets / pinned-source locations:

The original report labels the top frame ares_llist_node_next + 4364492 and the next v8::SharedValueConveyor + 46064. These are misleading nearest exported symbols from the stripped binary, not evidence of a DNS or V8-conveyor failure.

Bounds failure confirmed by disassembly and registers

Disassembly of the matching installed framework shows x1 is the string-view length and x2 is the requested index:

0x674488c: mov x8, x0
0x6744890: mov w0, #1
0x6744894: cbz x2, 0x67448d0
0x6744898: cmp x2, x1
0x674489c: b.eq 0x67448d0
0x67448a0: b.hs 0x67448d4
...                    // UTF-16 surrogate-boundary handling
0x67448d0: ret
0x67448d4: brk #1

Crash thread registers:

x1 = 0       // text length
x2 = 2975    // requested UTF-16 index
pc = 0x1159908d4  // framework-relative 0x67448d4
lr = 0x111d869cc  // framework-relative 0x2b3a9cc
esr: (Breakpoint) brk 1

The link register independently resolves the immediate caller omitted from the original unwound frames. Its preceding instruction at 0x2b3a9c8 calls gfx::IsValidCodePointIndex from AsLeafTextPositionBeforeCharacter.

Pinned Chromium code:

• Cocoa line-range query: retrieves a stored line-start offset, creates a text position, then calls CreatePreviousLineStartPosition.
• Position normalization: the crashing call is the loop invoking IsValidCodePointIndex(GetText(), text_offset_) at line 3256.
• UTF-16 index helper: indexes the supplied string view when the index is neither zero nor its length.

macOS requester and crash-time correlation

Focused unified-log excerpts (Dubai time; unrelated app activity and personal paths omitted):

15:39:37.605 AXVisualSupportAgent[633] ERROR: attempt to initialize AXFTextRange with start position that is before the end position.
15:39:37.719 AXVisualSupportAgent[633] ERROR: containsPosition called with AXFTextPosition instance of incompatible type.
15:39:38.269 CursorUIViewService[843] ... com.apple.TextInputUI.xpc.CursorUIViewService.peer[10656] ...
15:39:38.297 T3 Code (Nightly)[10656] ... Create CursorUIViewService: TUINSRemoteViewController
15:39:38.306 AXVisualSupportAgent[633] AXFUIElement Timeout: [pid: 10656] [request: _AXFUIElementCopyParameterizedAttributeValue] [info: AXTextMarkerRangeForLine]
15:39:38.306 AXVisualSupportAgent[633] Attempted to get line index with invalid position.
15:39:38.3527 macOS crash capture timestamp for T3 Code (Nightly)[10656]

These logs identify an observed requester of the same query as the crashing path. They do not establish which particular IPC request trapped or why the text state became inconsistent. Crash-capture and log timestamps are not a substitute for a trace of the exact trap instant.

Read-only preference inspection during diagnosis found Hover Text, Hover Typing, and Hover Color off. Those are current settings, not a historical crash-time snapshot. Please do not infer a Hover Typing/dictation prerequisite from the presence of Apple's accessibility agent.

Other local evidence

• Inspected desktop trace spans from 15:39:00–15:40:00 have no failed exits. Final pre-crash IPC completed successfully at 15:39:35.442985.
• Renderer working set at 15:39:26.742 was approximately 489 MiB, with a recorded peak of approximately 565 MiB. That sample does not rule out every memory issue, but the confirmed termination here is a text-index bounds assertion, not an OOM signature.
• Server t3.json read failures at 15:39:38.378940 and subscription interruptions at 15:39:38.408493 occurred after the recorded crash timestamp. They do not explain this native bounds trap.
• Renderer history records the application subsequently relaunched with a new main PID at 15:40:04.597. No database-integrity or complete task-recovery audit was performed.

Diagnosis / remaining unknowns

Confirmed: a macOS accessibility line-range query reaches a nonzero UTF-16 offset with an empty text string and kills Electron's main process through a native bounds assertion. Apple's AXVisualSupportAgent is observed making that query against T3 at the crash boundary.

Not established: the specific DOM/accessibility node, which surface/input was affected, why text and offset diverged, a deterministic repro, whether the mismatch is caused by stale line starts/tree state or another Chromium defect, or which macOS feature initiated the observed queries.

The useful next investigation is to trace the anchor/node ID, stored line-start offset, MaxTextOffset(), and actual GetText().size() across this native accessibility path while T3 updates text. An Electron version change should be verified against a reproduction before claiming it fixes the issue. This report does not propose disabling accessibility globally or changing ordinary agent orchestration.

Workaround

Relaunching restores the desktop UI; prevention is unverified. No application/settings/data changes were made during diagnosis.