wez
imgcat panic when invoked from powershell under WSL paths
What Operating System(s) are you seeing this problem on?
Windows
Which Wayland compositor or X11 Window manager(s) are you using?
The above doesn't apply. I'm on Arch Linux on WSL2 on Windows 11.
Linux mechrevo 5.15.133.1-microsoft-standard-WSL2 #1 SMP Thu Oct 5 21:02:42 UTC 2023 x86_64 GNU/Linux
Windows 11 v22H2(22621.1265).
wezterm is installed on windows 11 while I'm invoking the command via something like wezterm.exe ....
WezTerm version
wezterm 20240129-220340-47f647ca
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
Trying to run wezterm.exe imgcat failed.
To Reproduce
- Install wezterm.exe and run Arch WSL on it
- Start a bash shell in ArchWSL
- run
WSLENV=RUST_BACKTRACE/w RUST_BACKTRACE=full wezterm.exe imgcat `wslpath -w your_image_path_here`
- failed with this:
09:27:46.757 ERROR env_bootstrap > panic at wezterm\src\main.rs:377:10 - attempt to divide by zero
0: <unknown>
1: <unknown>
2: <unknown>
3: git_filter_source_repo
4: git_filter_source_repo
5: git_filter_source_repo
6: git_filter_source_repo
7: git_credential_username_new
8: git_credential_username_new
9: <unknown>
10: <unknown>
11: <unknown>
12: <unknown>
13: git_filter_source_repo
14: <unknown>
15: git_credential_username_new
16: BaseThreadInitThunk
17: RtlUserThreadStart
thread 'main' panicked at wezterm\src\main.rs:377:10:
attempt to divide by zero
stack backtrace:
0: 0x7ff6d8be17d3 - git_filter_source_repo
1: 0x7ff6d8c09d0d - git_filter_source_repo
2: 0x7ff6d8bdbac1 - git_filter_source_repo
3: 0x7ff6d8be15da - git_filter_source_repo
4: 0x7ff6d8be3e69 - git_filter_source_repo
5: 0x7ff6d8be3b2b - git_filter_source_repo
6: 0x7ff6d7ff4620 - <unknown>
7: 0x7ff6d8be4383 - git_filter_source_repo
8: 0x7ff6d8be41eb - git_filter_source_repo
9: 0x7ff6d8be20c9 - git_filter_source_repo
10: 0x7ff6d8be3f34 - git_filter_source_repo
11: 0x7ff6d9078297 - git_credential_username_new
12: 0x7ff6d9078352 - git_credential_username_new
13: 0x7ff6d7f2a63b - <unknown>
14: 0x7ff6d7f2c61c - <unknown>
15: 0x7ff6d7eb9e96 - <unknown>
16: 0x7ff6d7fc8f1c - <unknown>
17: 0x7ff6d8bd2a38 - git_filter_source_repo
18: 0x7ff6d7fc8f08 - <unknown>
19: 0x7ff6d8fed1cc - git_credential_username_new
20: 0x7ffaa4c626bd - BaseThreadInitThunk
21: 0x7ffaa61edfb8 - RtlUserThreadStart
Configuration
-- Pull in the wezterm API
local wezterm = require 'wezterm'
-- This table will hold the configuration.
local config = {}
-- In newer versions of wezterm, use the config_builder which will
-- help provide clearer error messages
if wezterm.config_builder then
config = wezterm.config_builder()
end
-- This is where you actually apply your config choices
config.default_prog = { 'D:\\Apps\\ArchWSL\\Arch.exe' }
config.font = wezterm.font 'FiraCode Nerd Font'
-- and finally, return the configuration to wezterm
return config
Expected Behavior
No bug, image displayed
Logs
09:28:42.446 ERROR env_bootstrap > panic at wezterm\src\main.rs:377:10 - attempt to divide by zero
0: <unknown>
1: <unknown>
2: <unknown>
3: git_filter_source_repo
4: git_filter_source_repo
5: git_filter_source_repo
6: git_filter_source_repo
7: git_credential_username_new
8: git_credential_username_new
9: <unknown>
10: <unknown>
11: <unknown>
12: <unknown>
13: git_filter_source_repo
14: <unknown>
15: git_credential_username_new
16: BaseThreadInitThunk
17: RtlUserThreadStart
Anything else?
No response
this does work when I launch powershell from wezterm directly and use imgcat, however.
I'm not clear what you're trying here; are you saying that the wezterm.exe imgcat invocation is what is panicking?
What are the conditions that cause it to panic? Your summary suggests that it is to do with the path, but it doesn't indicate what the path is.
Please provide more information.
I just refined the description. This bug occurs when I run wsl and the default path is a WSL path, running wezterm.exe imgcat it will panic.
In my experiments, switching to powershell from WSL bash and run $env:RUST_BACKTRACE = 'full'; wezterm.exe imgcat someimage.png will also panic. However starting wezterm with powershell directly with wezterm.exe -e "powershell.exe", cd into the windows path and run the command for powershell yields no panic.
Just did a bit of debugging myself. It seems that the issue is related to the conpty issue mentioend in https://github.com/wez/wezterm/issues/4029.
When I run wezterm imgcat <img> (with a png file) in WSL, I also get this error. I did a bit of debugging and tracked the issue down to https://github.com/wez/wezterm/blob/c3d37f9edae6951bbb564197a62bb433a289ff4f/wezterm/src/main.rs#L377.
Fixing this issue in general would be interesting, but in my particular case, I don't really care about the cursor. It seems this value is only used when needs_force_cursor_move is true. Would you be open to a PR that calls compute_image_cell_dimensions lazily only when needs_force_cursor_move is true?
If so, I can try running wezterm imgcat --no-move-cursor <img> to see if that avoids the division by zero.
Ah yes, this is a duplicate of https://github.com/wez/wezterm/issues/4029 @TzviPM if you'd like to take a stab at resolving this, I'd welcome it. I think there are a couple of things that could be done:
- If we get 0 for the cell dimensions, we could either:
- Explain the issue with a nicer error message
- just assume a reasonable default value
- Increasing this timeout may prevent this from cropping up as much:
https://github.com/wez/wezterm/blob/767e72a17b46c7fe695b34c592bf0961deddef14/termwiz/src/caps/probed.rs#L154-L163
If you're feeling up to making a PR, I'd rather that you looked at those two things than skirting around the math!
And yes, I would love to see a PR for this: I'm not actively doing dev on Windows recently, and I'm unlikely to have time to do so in the near future.
I can replicate this on macOS running wezterm imgcat inside of tmux. I didn't report previously because I was under the impression that wezterm imgcat was not supported inside of tmux, but I do accidentally do this and the error message surprises me. :smile:
RUST_BACKTRACE=full wezterm imgcat "Bildschirmfoto 2023-12-08 um 3.35.24 PM.png"
09:56:46.758 ERROR env_bootstrap > panic at wezterm/src/main.rs:383:10 - attempt to divide by zero
0: backtrace::capture::Backtrace::create
1: backtrace::capture::Backtrace::new
2: env_bootstrap::register_panic_hook::{{closure}}
3: std::panicking::rust_panic_with_hook
4: std::panicking::begin_panic_handler::{{closure}}
5: std::sys_common::backtrace::__rust_end_short_backtrace
6: _rust_begin_unwind
7: core::panicking::panic_fmt
8: core::panicking::panic
9: wezterm::ImgCatCommand::compute_image_cell_dimensions
10: wezterm::run
11: wezterm::main
12: std::sys_common::backtrace::__rust_begin_short_backtrace
13: std::rt::lang_start::{{closure}}
14: std::rt::lang_start_internal
15: std::rt::lang_start
16: _main
thread 'main' panicked at wezterm/src/main.rs:383:10:
attempt to divide by zero
stack backtrace:
0: 0x105d4b83c - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h298c9ab285ff3934
1: 0x105d702c4 - core::fmt::write::h4e276abdb6d0c2a1
2: 0x105d46fc4 - std::io::Write::write_fmt::hd421848f5f0bf9d0
3: 0x105d4b678 - std::sys_common::backtrace::print::hd8bd9ecab1f94b94
4: 0x105d4d1b4 - std::panicking::default_hook::{{closure}}::h520eeb743fc98fb4
5: 0x105d4cefc - std::panicking::default_hook::ha6550ffe49b63df1
6: 0x104fbaadc - env_bootstrap::register_panic_hook::{{closure}}::h9b094f72f93dc696
7: 0x105d4d714 - std::panicking::rust_panic_with_hook::hddb0e884a202de7c
8: 0x105d4d4b8 - std::panicking::begin_panic_handler::{{closure}}::hd2798398a2fd9077
9: 0x105d4bca4 - std::sys_common::backtrace::__rust_end_short_backtrace::h9201cc364dbb8a23
10: 0x105d4d278 - _rust_begin_unwind
11: 0x105de18b0 - core::panicking::panic_fmt::h4d5168028d4c43c7
12: 0x105de1924 - core::panicking::panic::h40561ff494e2b577
13: 0x104f44810 - wezterm::ImgCatCommand::compute_image_cell_dimensions::hf4a654b8b44bc0f5
14: 0x104f47fd4 - wezterm::run::hdda5256d415fecb7
15: 0x104f450b4 - wezterm::main::h4e75f015b192b1cc
16: 0x104ea53dc - std::sys_common::backtrace::__rust_begin_short_backtrace::h2263a45c221c762d
17: 0x104f9db38 - std::rt::lang_start::{{closure}}::haf77dd2d3edcb4a6
18: 0x105d3e5dc - std::rt::lang_start_internal::h5b246d44f1526226
19: 0x104f9db1c - std::rt::lang_start::h9e31e61e00da983c
20: 0x104f52f2c - _main
I'm facing the exact same problem on NixOS, Wayland, tmux. I just installed wezterm; the first run of imgcat worked, and then this.
this does work when I launch powershell from wezterm directly and use imgcat, however.
I am experiencing similar behavior with another setup: Slackware64-15.0 Linux and WezTerm-20240203-110809-5046fc22-Ubuntu20.04.AppImage
- start wezterm
- inside it type
wezterm imgcat img.png - everything works
- start another GUI terminal emulator (I use
xfce4-terminal) - inside it type
wezterm imgcat img.png - it fails with the backtrace attached above
Getting this too, but on : Amazon Linux 2 (loosely Fedora)
❯ wezterm --version
wezterm 20240506-145255-0b50725f
❯ RUST_BACKTRACE=1 http GET 'https://www.tradegate.de/images/charts/intraday/GB00B18S7B29.png?1675672080'
| wezterm imgcat --no-resample --no-move-cursor --hold
13:29:45.466 ERROR env_bootstrap > panic at wezterm/src/main.rs:383:10 - attempt to divide by zero
0: env_bootstrap::register_panic_hook::{{closure}}
1: std::panicking::rust_panic_with_hook
2: std::panicking::begin_panic_handler::{{closure}}
3: std::sys_common::backtrace::__rust_end_short_backtrace
4: rust_begin_unwind
5: core::panicking::panic_fmt
6: core::panicking::panic
7: wezterm::ImgCatCommand::compute_image_cell_dimensions
8: wezterm::run
9: wezterm::main
10: std::sys_common::backtrace::__rust_begin_short_backtrace
11: std::rt::lang_start::{{closure}}
12: std::rt::lang_start_internal
13: main
14: __libc_start_main
at /usr/src/debug/glibc-2.26-193-ga0bc5dd3be/csu/../csu/libc-start.c:308
15: _start
thread 'main' panicked at wezterm/src/main.rs:383:10:
attempt to divide by zero
