Runtime safety crash if searching on `yes`

[mitchellh]

There is a runtime safety panic that can occur if you search for "y" when running yes. I also tried "ye" on yes yes to see if this was a single-char needle issue and it happens in both cases, so it doesn't matter.

Here is the stack I got:

I got exact lines too but lost them in this screenshot, it's easy to reproduce. I unfortunately am not sure why it happens yet.

[mitchellh]

Note: I haven't been able to get this to crash in a release build, but I'm sure it's causing some kind of memory corruption somewhere eventually. I'm not sure.

[theodoretliu]

I think I ran into a crash in a release build related to this. Running on version 9baf37a9b

Behavior right before crash: I was running a test-suite and opened up the new search capabilities while it was still outputting. I think I typed "r" (planned to search for "rspec") and then Ghostty quit.

Per the README.md I was able to find the crashdump and I sent it over to your Sentry.

Wish I could be more help!

[kemko]

I'm not sure if it's the same bug or a different one, but here's how I was able to crash the terminal:

1. Run the command yes|head -n 10000
2. Open the search bar and search for y
3. Open another tab.

There is my settings:

auto-update-channel = tip

font-size = 14
font-family = "Maple Mono Normal NF"
window-padding-x = 8,4
window-show-tab-bar = always

macos-option-as-alt = true
macos-non-native-fullscreen = visible-menu


command = /opt/homebrew/bin/fish --login --interactive
shell-integration-features = no-cursor,sudo,title,ssh-env

window-vsync = false
# quit-after-last-window-closed = true

keybind = global:ctrl+grave_accent=toggle_quick_terminal
keybind = super+r=reload_config

scrollback-limit = 100000000