Certain characters simply crash WezTerm

[0neGal]

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

Windows, Linux X11, Linux Wayland, macOS, FreeBSD X11, FreeBSD Wayland

WezTerm version

20210814-124438-54e29167

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

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

As the title suggests, certain characters at least when there's a lot of them crashes WezTerm, few of them usually just temporarily slows down WezTerm or causes issues when inside tui's.

To Reproduce

1. Get a hold of an mp3 or otherwise non-plain-text file
   • mp3/mp4 or other audio/video files are the easiest for reproducing
2. View the contents (i.e cat file.mp3)
3. Watch as the terminal either dramatically slows down then crashes or outright just crashes instantly.

Configuration

No configuration is needed, while with my config it actually crashes faster (My guess would be because of my extra fonts maybe?) it still is not needed for it to crash.

Expected Behavior

Either not display a character when a character that would otherwise crash the terminal or display the correct character if there is one at all.

Logs

There's quite a few things here, first the errors:

ERROR termwiz::escape::parser                > impossible C0/C1 control code '\u{80}' 0x80 was dropped

And every so often

ERROR termwiz::escape::parser                > finished sixel parse with 2 bytes pending Ok("\"w")

Then at some point the errors turn into warnings, I say turn into since they look quite similar in terms of what they're about (I'm guessing):

WARN  wezterm_term::terminalstate::performer > unhandled ControlCode SS2

The actual control code vary widely.
And there's also this

WARN  wezterm_term::terminalstate::performer > ESC: unhandled Unspecified { intermediate: None, control: 100 }

Interestingly in the midst of all the warnings you get a bell

INFO  wezterm_gui::frontend                  > Ding! (this is the bell)

And finally it crashes like so:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: FloatIsNan', term/src/terminalstate/image.rs:85:85
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread '<unnamed>' panicked at 'task has failed', /build/.cargo/registry/src/github.com-1ecc6299db9ec823/async-task-4.0.3/src/task.rs:368:45
 2021-08-21T17:43:24.162Z ERROR mux                                    > read_pty failed to write to parser: pane 0 Os { code: 104, kind: ConnectionReset, message: "Connection reset bypeer" }

As I said before, printing only a couple of the characters doesn't crash WezTerm so if you want you could just head file.mp3 and it'd give errors and warning but not crash.

Anything else?

This is an outtake from another issue #1058, discussing this same issue, and why I even care about it being fixed, it's not like you'll go around cat'ing audio/video files randomly.

This isn't that big of a deal by itself because who would ever cat a file like that. The issue arrises since I use fzf to open files, which then cats the files on the right side so I can preview them, that means if fzf gets a file that's binary content or similar it'll usually crash. I don't know if there's any easy way to fix this, and it might need a separate issue on it's own.

[wez]

thread 'main' panicked at 'called Result::unwrap() on an Err value: FloatIsNan', term/src/terminalstate/image.rs:85:85 note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

That code doesn't exist in the nightly builds; it was refactored in #1031 so I'd suggest running the nightly.

BTW: In the details you filled out in the bug submission form, you indicated that you'd already tried the nightly and that you'd revised the version in your report to match. It also indicates that you're running this on all of the different supported operating systems. Is there something not working right with the form submission?

Regarding the logs: I totally expect to see random warnings/errors when cating random data into the terminal. But we shouldn't crash!

[0neGal]

you indicated that you'd already tried the nightly

My bad here, I actually assumed since you'd never heard of the bug in the other issue we had that it was unknown, I should've tested it, compiling it and running it, it's fixed albeit gives some funny output to the terminal, but it doesn't crash. It does however significantly slow down, and with my tiny little fzf program it becomes unusable if I happen to get to a file that'd cause this behaviour. Which is easier than you'd think.

It also indicates that you're running this on all of the different supported operating systems

I actually assumed that was more or a checkbox for what platforms the issue occurs on and not my current platform, my bad again! Which I was totally guessing the platforms, which now that I think of it, ticking my current platform makes more sense. Perhaps rename it to "What platform(s) are you running WezTerm on?", idk perhaps I'm just a little bit dumb hehe

So overall the issue is mildly fixed albeit it slowing down, but not sure if there's really much to do, considering what data is being parsed...

[wez]

FWIW, the nightly builds all have pre-built binaries for various platforms, so it should be relatively low friction to test (especially the AppImage!)

Re: the slowdown, if you built it yourself, did you build in --release mode?

[0neGal]

FWIW, the nightly builds all have pre-built binaries for various platforms, so it should be relatively low friction to test (especially the AppImage!)

See I tried to install the nightly build from the AUR, however I got various errors:

fuse: device not found, try 'modprobe fuse' first
open dir error: No such file or directory
==> ERROR: pkgver is not allowed to contain colons, forward slashes, hyphens or whitespace.
==> ERROR: pkgver() generated an invalid version:
mount
might
you
https://github.com/AppImage/AppImageKit/wiki/FUSE
more
error: failed to build 'wezterm-nightly-bin-20200517.122836.92c201c6.105.g5d508350-8':
error: packages failed to build: wezterm-nightly-bin-20200517.122836.92c201c6.105.g5d508350-8

And so I installed wezterm-git instead, not sure if --release is what that compiles with.

[0neGal]

Besides the whole issue with the AUR build there's nothing more to fix or discuss!

[github-actions[bot]]

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.