Open takase1121 opened 7 months ago
I also just noticed this. Seems the same as https://github.com/wez/wezterm/issues/4825
Using OpenGL as a work-around for now https://github.com/wez/wezterm/issues/4825#issuecomment-1902494625
Do you see wgpu panicking when it falls over? Please share that part of the logs. What you shared is a generic message from the system wayland libraries which doesn't help identify where in wezterm a problem may be coming from.
I do agree that this is likely correlated with the recent wgpu dependency upgrade, I would just like to have a bit more detail so I can report this with the wgpu folks and figure out a solution.
I have the same problem
I've reverted the wgpu 0.19 upgrade in main
.
I don't know if this was mentioned elsewhere, but I also had crazy amounts of ram being taken up by wezterm on macOS after an earlier update today. Updating again after you reverted wgpu has fixed it. (Just wanted to mention that this also affected macOS and was not only affecting Linux.)
I am running into the same issue. I started wezterm with
$ RUST_BACKTRACE=full wezterm
but the dump I get isn't terribly useful. Still, here is what dumps when it crashes
17:13:40.352 ERROR wgpu::backend::wgpu_core > Handling wgpu errors as fatal by default
17:13:40.353 ERROR env_bootstrap > panic at /home/miversen/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wgpu-0.19.0/src/backend/wgpu_core.rs:3009:5 - !?
0: <unknown>
1: <unknown>
2: <unknown>
3: <unknown>
4: <unknown>
5: <unknown>
6: <unknown>
7: <unknown>
8: <unknown>
9: <unknown>
10: <unknown>
11: <unknown>
12: <unknown>
13: <unknown>
14: <unknown>
15: <unknown>
16: <unknown>
17: <unknown>
18: <unknown>
19: <unknown>
20: <unknown>
21: <unknown>
22: <unknown>
23: <unknown>
24: <unknown>
25: <unknown>
26: <unknown>
27: __libc_start_main
28: <unknown>
thread 'main' panicked at /home/miversen/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wgpu-0.19.0/src/backend/wgpu_core.rs:3009:5:
wgpu error: Validation Error
Caused by:
In Device::create_buffer
note: label = `Vertex Buffer`
Not enough memory left.
stack backtrace:
0: 0x5647f1bca79c - <unknown>
1: 0x5647f1bfe09c - <unknown>
2: 0x5647f1bc49ae - <unknown>
3: 0x5647f1bca584 - <unknown>
4: 0x5647f1bcc3c3 - <unknown>
5: 0x5647f1bcc0e4 - <unknown>
6: 0x5647f009bbf8 - <unknown>
7: 0x5647f1bccac1 - <unknown>
8: 0x5647f1bcc841 - <unknown>
9: 0x5647f1bcacc6 - <unknown>
10: 0x5647f1bcc592 - <unknown>
11: 0x5647efc880b5 - <unknown>
12: 0x5647f0325139 - <unknown>
13: 0x5647f0334a34 - <unknown>
14: 0x5647f033d94d - <unknown>
15: 0x5647f0306233 - <unknown>
16: 0x5647efea5c7c - <unknown>
17: 0x5647eff5385f - <unknown>
18: 0x5647eff6a70f - <unknown>
19: 0x5647f003ea6d - <unknown>
20: 0x5647f0c75a18 - <unknown>
21: 0x5647f0c16a3c - <unknown>
22: 0x5647f0da625b - <unknown>
23: 0x5647f0d6c158 - <unknown>
24: 0x5647f0c2c0cf - <unknown>
25: 0x5647f0c0bae7 - <unknown>
26: 0x5647efeb0794 - <unknown>
27: 0x5647efeb270d - <unknown>
28: 0x5647efe22583 - <unknown>
29: 0x5647eff14299 - <unknown>
30: 0x5647f1bbb05b - <unknown>
31: 0x5647efeb97f5 - <unknown>
32: 0x7fe5b3245cd0 - <unknown>
33: 0x7fe5b3245d8a - __libc_start_main
34: 0x5647efc88895 - <unknown>
35: 0x0 - <unknown>
@miversen33 if you can build from source without --release
, you should get a more useful stack trace
It's a chunky boy, here ya go. This is against 7c452d3 which as far as I could tell was the last commit before the revert.
Some specific details about my system. I am running Arch, KDE with X11 on an Intel i5-12500H and an integrated Intel Iris XE Graphics "card".
12: <T as wgpu::context::DynContext>::device_create_buffer
at /home/miversen/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wgpu-0.19.0/src/context.rs:2287:30
13: wgpu::Device::create_buffer
at /home/miversen/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wgpu-0.19.0/src/lib.rs:2514:13
14: wezterm_gui::renderstate::WebGpuVertexBuffer::recreate
at wezterm-gui/src/renderstate.rs:239:27
15: wezterm_gui::termwindow::render::draw::<impl wezterm_gui::termwindow::TermWindow>::call_draw_webgpu
at wezterm-gui/src/termwindow/render/draw.rs:133:37
16: wezterm_gui::termwindow::render::draw::<impl wezterm_gui::termwindow::TermWindow>::call_draw
at wezterm-gui/src/termwindow/render/draw.rs:16:36
17: wezterm_gui::termwindow::render::paint::<impl wezterm_gui::termwindow::TermWindow>::paint_impl
at wezterm-gui/src/termwindow/render/paint.rs:108:9
@miversen33 thanks; I think what you're seeing is probably the same as #4825, but both are fundamentally related to the wgpu update. I think your hardware/driver combo panics whereas the amd flavor keeps growing
Do you see wgpu panicking when it falls over? Please share that part of the logs. What you shared is a generic message from the system wayland libraries which doesn't help identify where in wezterm a problem may be coming from.
I do agree that this is likely correlated with the recent wgpu dependency upgrade, I would just like to have a bit more detail so I can report this with the wgpu folks and figure out a solution.
I wasn't able to get it panic before the system completely hangs from OOM, but I doubt it would matter since OOM sends a SIGTERM followed by a SIGKILL or a SIGKILL.
I had to use the Magic Sysrq keys to stop it from hanging, but when I inspect the log directory there's nothing in it.
What Operating System(s) are you seeing this problem on?
Linux Wayland
Which Wayland compositor or X11 Window manager(s) are you using?
Operating System: Arch Linux KDE Plasma Version: 5.27.10 KDE Frameworks Version: 5.114.0 Qt Version: 5.15.12 Kernel Version: 6.7.0-zen3-1-zen (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 5500U with Radeon Graphics Memory: 5.6 GiB of RAM Graphics Processor: AMD Radeon Graphics Manufacturer: LENOVO Product Name: 82LM System Version: IdeaPad 5 14ALC05
WezTerm version
20240120-211320-b4c5dc74
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
Wezterm keeps on expanding VRAM and GTT (shared memory between CPU and GPU) until it runs out of memory. This happens especially with interactive terminal applications, e.g. htop, nano. After wezterm is closed, the memory is freed properly.
To Reproduce
config.front_end = "WebGpu"
which is the default)Configuration
Expected Behavior
To have it not explode on my face and OOM everything.
Logs
Anything else?
Here is a video of it filling up my RAM.
https://github.com/wez/wezterm/assets/20792268/1cc4b614-c1e6-4484-8f90-e6bea28ef46b