Repeated SIGABRT crash in GridHandler::resize (InitialCursorState::into_content_offset unwrap panic)

[choiseongh]

Description

Warp crashes repeatedly with SIGABRT due to a Rust panic in the terminal grid resize path. The crash occurs when the terminal view layout triggers a resize operation, and InitialCursorState::into_content_offset encounters an unexpected Err value that is unwrap()-ed.

This is highly reproducible — 8 crashes recorded over the past week, with 7/8 sharing the exact same stack trace. On April 4th alone, Warp crashed 6 times.

Environment

• Warp version: 0.2026.03.25.08.24.05 (Stable)
• OS: macOS 26.3.1 (Build 25D771280a)
• Hardware: MacBook Pro, Apple M3, 8 GB RAM
• Architecture: ARM-64 (native, not translated)

Crash Stack Trace (faulting thread 0)

All crashes share this identical call chain:

 0  libsystem_kernel.dylib       __pthread_kill
 1  libsystem_pthread.dylib      pthread_kill
 2  libsystem_c.dylib            abort
 3  stable                       std::sys::pal::unix::abort_internal
 4  stable                       std::process::abort
 5  stable                       rust_panic
 6  stable                       std::panicking::panic_with_hook
 7  stable                       std::panicking::panic_handler
 8  stable                       std::sys::backtrace::__rust_end_short_backtrace
 9  stable                       rust_begin_unwind
10  stable                       core::panicking::panic_fmt
11  stable                       core::result::unwrap_failed          ← unwrap on Err
12  stable                       warp::terminal::model::grid::grid_handler::resize::InitialCursorState::into_content_offset
13  stable                       warp::terminal::model::grid::grid_handler::resize::GridHandler::resize_storage
14  stable                       warp::terminal::model::grid::grid_handler::resize::GridHandler::resize
15  stable                       warp::terminal::model::blocks::BlockList::resize
16  stable                       warp::terminal::model::terminal_model::TerminalModel::resize
17  stable                       warp::terminal::view::TerminalView::resize_internal
18  stable                       warp::terminal::view::TerminalView::after_terminal_view_layout

Crash Timeline

Timestamp	Crash file
2026-03-29 20:42	stable-2026-03-29-204208.ips
2026-04-02 21:44	stable-2026-04-02-214416.ips
2026-04-04 16:22	stable-2026-04-04-162222.ips
2026-04-04 16:57	stable-2026-04-04-165702.ips
2026-04-04 17:00	stable-2026-04-04-165959.ips
2026-04-04 17:01	stable-2026-04-04-170142.ips
2026-04-04 17:12	stable-2026-04-04-171234.ips
2026-04-04 17:12	stable-2026-04-04-171242.ips

Suspected Trigger

The crash appears to be triggered by terminal resize events — possibly from:

• Window resizing
• Stage Manager view transitions
• Split view changes
• External display connect/disconnect

The root cause seems to be an invalid internal grid state when InitialCursorState::into_content_offset is called during GridHandler::resize_storage, causing an unwrap() on an Err result.

Suggested Fix

Consider replacing the unwrap() in InitialCursorState::into_content_offset with proper error handling (e.g., unwrap_or_default() or propagating the error) to prevent the panic, or validate the grid state before entering the resize path.

[Mtartup]

+1 — Same crash here.

• Warp version: 0.2026.04.08.08.36.02 (Stable)
• OS: macOS 26.4.1 (25E253)
• Hardware: Mac17,8 (ARM-64, native)
• Crash count: 7 crashes in 2 days (5 on April 12 alone)

Identical stack trace — InitialCursorState::into_content_offset panic at grid/resize.rs:281 during TerminalView::resize_internal.

Triggered by running Claude Code in Warp — heavy terminal output appears to cause internal reflow/resize that hits the bug. Every crash is preceded by a burst of window resized events in the log.

SQLite WAL recovery was also observed on restart (recovered 196 frames from WAL file), suggesting the abort leaves the DB in an unclean state.

[aideedamsyar]

Adding a third reproduction of this crash.

• Warp version: 0.2026.05.18.05.32.02 (Stable)
• OS: macOS 15.6 (24G84), Mac16,12, ARM-64 native
• Crashes: 4 in ~5 minutes on 2026-05-20, all with identical stack ending at InitialCursorState::into_content_offset → unwrap_failed.
• Panic message (from ~/Library/Logs/warp.log):
  panicked at 'should have a content offset for point: ColumnExceedsContent { row: 0, col: 76 }': app/src/terminal/model/grid/resize.rs:298
• Trigger: launch only — Warp restored the previous session's blocks and immediately panicked during the initial layout-driven resize before any window interaction.
• Workaround: moving aside warp.sqlite / -wal / -shm in ~/Library/Group Containers/2BBY89MBSN.dev.warp/.../dev.warp.Warp-Stable/. So the bad state is persistent in SQLite — once a session writes a cursor at a column past its row's content, every subsequent launch crashes until the DB is wiped. That makes the panic effectively unrecoverable without filesystem surgery, which strengthens the case for Stop crashing on out-of-bounds cursor during resize (#9013) #9664's graceful-fallback approach.
• The bad DB is preserved as .bak files; happy to share offline if useful for a regression fixture.