wez / wezterm

A GPU-accelerated cross-platform terminal emulator and multiplexer written by @wez and implemented in Rust
https://wezfurlong.org/wezterm/
Other
17.9k stars 801 forks source link

Random crashes due to specific unicode/control characters? #3338

Closed xorander00 closed 1 year ago

xorander00 commented 1 year ago

What Operating System(s) are you seeing this problem on?

FreeBSD X11

Which Wayland compositor or X11 Window manager(s) are you using?

awesome • Compiled against Lua 5.3.6 (running with Lua 5.3) • D-Bus support: ✔ • execinfo support: ✔ • xcb-randr version: 1.6 • LGI version: 0.9.2

WezTerm version

wezterm 20221119-145034-49b9839f

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

No, and I'll explain why below

Describe the bug

Terminal randomly crashed when I was AFK a few days ago. When I got back I launched it again, along with the applications I had running (Fish, NeoVim, WeeChat). It randomly crashed again and after a bit of trial-and-error, figured out it was when I was switching to a specific WeeChat channel. I guess there was something in the channel log that was causing WezTerm to crash, so I moved that log and was able to switch to the channel fine.

Then just now, it happened again, this time when I was switching to the view for a specific RSS feed (https://reddit.com/r/kotlin). When I disabled that feed from my list, it worked fine.

Log shows SIGSEGV, but no warnings/errors right before it. I've also attached a screenshot of the posts in the feed as viewed in my browser. I wonder if the emoji in post number two in the screenshot might be triggering something? Not sure, just guessing. I've also attached the actual RSS document that's being rendered in my TUI app (https://github.com/veeso/tuifeed).

To Reproduce

Not sure how yet, but open to helping drill down what might be causing it with the context I've provided.

Configuration

Don't have immediate access at the moment, but let me know if there are any specific parts you would like to see. I can grab those later when I'm back.

Expected Behavior

Not crash when rendering specific text?

Logs

15:30:39.488 DEBUG wezterm_font::shaper::harfbuzz > hb info.cluster 0 -> Info { cluster: 0, len: 1, codepoint: 686, x_advance: 640, y_advance: 0, x_offset: 0, y_offset: 0 } 15:30:39.488 DEBUG wezterm_font::shaper::harfbuzz > hb info.cluster 1 -> Info { cluster: 1, len: 1, codepoint: 686, x_advance: 640, y_advance: 0, x_offset: 0, y_offset: 0 } 15:30:39.488 DEBUG wezterm_font::shaper::harfbuzz > hb info.cluster 2 -> Info { cluster: 2, len: 1, codepoint: 686, x_advance: 640, y_advance: 0, x_offset: 0, y_offset: 0 } 15:30:39.488 DEBUG wezterm_font::shaper::harfbuzz > hb info.cluster 3 -> Info { cluster: 3, len: 1, codepoint: 686, x_advance: 640, y_advance: 0, x_offset: 0, y_offset: 0 } 15:30:39.488 DEBUG wezterm_font::shaper::harfbuzz > hb info.cluster 4 -> Info { cluster: 4, len: 1, codepoint: 686, x_advance: 640, y_advance: 0, x_offset: 0, y_offset: 0 } 15:30:39.488 DEBUG wezterm_font::shaper::harfbuzz > hb info.cluster 5 -> Info { cluster: 5, len: 1, codepoint: 686, x_advance: 640, y_advance: 0, x_offset: 0, y_offset: 0 } 15:30:39.488 DEBUG wezterm_font::shaper::harfbuzz > hb info.cluster 6 -> Info { cluster: 6, len: 1, codepoint: 686, x_advance: 640, y_advance: 0, x_offset: 0, y_offset: 0 } 15:30:39.488 DEBUG wezterm_font::shaper::harfbuzz > hb info.cluster 7 -> Info { cluster: 7, len: 1, codepoint: 686, x_advance: 640, y_advance: 0, x_offset: 0, y_offset: 0 } 15:30:39.488 DEBUG wezterm_font::shaper::harfbuzz > hb info.cluster 8 -> Info { cluster: 8, len: 1, codepoint: 686, x_advance: 640, y_advance: 0, x_offset: 0, y_offset: 0 } 15:30:39.488 DEBUG wezterm_font::shaper::harfbuzz > hb info.cluster 9 -> Info { cluster: 9, len: 1, codepoint: 686, x_advance: 640, y_advance: 0, x_offset: 0, y_offset: 0 } 15:30:39.488 DEBUG wezterm_font::shaper::harfbuzz > font_idx=0 info_clusters: [ [ Info { cluster: 0, len: 1, codepoint: 686, x_advance: 640, y_advance: 0, x_offset: 0, y_offset: 0, }, ], [ Info { cluster: 1, len: 1, codepoint: 686, x_advance: 640, y_advance: 0, x_offset: 0, y_offset: 0, }, ], [ Info { cluster: 2, len: 1, codepoint: 686, x_advance: 640, y_advance: 0, x_offset: 0, y_offset: 0, }, ], [ Info { cluster: 3, len: 1, codepoint: 686, x_advance: 640, y_advance: 0, x_offset: 0, y_offset: 0, }, ], [ Info { cluster: 4, len: 1, codepoint: 686, x_advance: 640, y_advance: 0, x_offset: 0, y_offset: 0, }, ], [ Info { cluster: 5, len: 1, codepoint: 686, x_advance: 640, y_advance: 0, x_offset: 0, y_offset: 0, }, ], [ Info { cluster: 6, len: 1, codepoint: 686, x_advance: 640, y_advance: 0, x_offset: 0, y_offset: 0, }, ], [ Info { cluster: 7, len: 1, codepoint: 686, x_advance: 640, y_advance: 0, x_offset: 0, y_offset: 0, }, ], [ Info { cluster: 8, len: 1, codepoint: 686, x_advance: 640, y_advance: 0, x_offset: 0, y_offset: 0, }, ], [ Info { cluster: 9, len: 1, codepoint: 686, x_advance: 640, y_advance: 0, x_offset: 0, y_offset: 0, }, ], ] fish: Job 1, '/usr/bin/env WEZTERM_LOG=wezter…' terminated by signal SIGSEGV (Address boundary error)

Anything else?

Screenshot 2023-03-23 at 15-44-16 Kotlin • r_Kotlin RSS feed text that was being loaded into my TUI app running in WezTerm

xorander00 commented 1 year ago

Ok, I just tried looking at the RSS document attached to this, and the terminal crashed, so it's definitely something in there. Here's what I tried...

# Crashed
bat feed.txt  

# Did NOT crash
nvim feed.txt

# Crashed
cat feed.txt

# Crashed (when trying to view /r/Kotlin)
tuifeed
wez commented 1 year ago

I can't reproduce this with the current release. In case the freebsd package is lagging (latest release was cut earlier this week), can you try building from source?

https://wezfurlong.org/wezterm/install/source.html

xorander00 commented 1 year ago

Yup, I started the build before heading out earlier. Just got back, installed it, verified the version, held my breath, and cat'ed that demon file.

Not crashing now :) wezterm 20230320-124340-559cb7b0

Strange that it was crashing before, wonder what was triggering it. Anyway, we can close the issue. Will re-open if it happens again. Thanks!

github-actions[bot] commented 1 year ago

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.