Wezterm becomes slow after some time, I have to close and re-run it

[fedxyz]

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

Linux X11

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

i3

WezTerm version

20250424-220948-1439661d

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

After some time I am using it wezterm it becomes very slow and unusable and it slows down my system.

As I said the system too becomes slow and I noticed an high cpu usage for Xorg process.

If I close all the wezterm terminal I am using it returns to normal and I can re-launch wezterm and it works good until the problem occurs again.

Most of the time I have two wezterm on my system with tmux and I run wezterm via i3's keybinding:

bindsym $mod+Return exec --no-startup-id wezterm start --always-new-process

the start --always-new-process was for testing because there was a warn in the log.

13:48:11.691  INFO   wezterm_gui > Spawned your command via the existing GUI instance. Use wezterm start --always-new-process if you do not want this behavior. Result=SpawnResponse { tab_id: 9, pane_id: 9, windo
w_id: 9, size: TerminalSize { rows: 24, cols: 80, pixel_width: 640, pixel_height: 384, dpi: 0 } }

To Reproduce

No response

Configuration

local wezterm = require 'wezterm'
local config = wezterm.config_builder()
config.hide_tab_bar_if_only_one_tab = true
config.color_scheme = 'Tokyo Night'
config.font = wezterm.font("JetBrainsMono Nerd Font") 
config.font_size = 11.0
config.force_reverse_video_cursor = true
return config

Expected Behavior

No response

Logs

Debug Overlay
wezterm version: 20250424-220948-1439661d x86_64-unknown-linux-gnu
Window Environment: X11 i3
Lua Version: Lua 5.4
OpenGL: Mesa Intel(R) UHD Graphics 630 (CML GT2) 4.6 (Compatibility Profile) Mesa 24.2.8-1ubuntu1~24.04.1
Enter lua statements or expressions and hit Enter.
Press ESC or CTRL-D to exit
16:07:07.486 WARN window::os::x11::connection > Unable to resolve appearance using xdg-desktop-portal: get_appearance.read_setting: Reading xdg-portal org.freedesktop.appearance color-scheme: org.freedesktop.DBus.Error.UnknownMethod: Interfaccia «org.freedesktop.portal.Settings» inesistente sull'oggetto nel percorso /org/freedesktop/portal/desktop

Anything else?

No response

[fedxyz]

an update, if this can help:

what I noticed is that using

watch -n 1 -- xwininfo -root -tree

I see the number of childrens that becomes very high (3000+) and this create the slow of the system I suppose.

There are a lot of windows like:

0x600759 (has no name): ()  1x1+0+0  +0+0

After I close wezterm it happens that the number decrease a lot, by 1500/2000.

Searching around about my problem I found this issue that was reported on picom issues list (I use picom too), https://github.com/yshui/picom/issues/1289#issuecomment-2244149866

I am not doing what he is testing on the video with wezterm and I don't see that "realtime" increment of 1x1 window, but for sure they increment in the time.

Another important test:

Still monitoring with

watch -n 1 -- xwininfo -root -tree

If I open wezterm and run tmux and I create new windows with Ctrl-b c , very often, not always, I see the number of 1x1+0+0 windows/childrens increasing a lot. And even if i close wezterm the number remains high.

[bew]

Hello, that linked picom issue mentions the use of fcitx as the IME. Do you have that on your system? Can you try disabling IME support using config.use_ime = false in your config, see if it improves things for you?

[fedxyz]

Hi, to be honest I don't know about IME: I read that is used to type languages like Chinese, Japanese etc., I don't know/use these languages.

I tried your suggestion and it's the same, to give you an idea this is what happen after I started my session, opened wezterm, run tmux and opened several window:

xwininfo: Window id: 0x4ac (the root window) "i3"

  Root window id: 0x4ac (the root window) "i3"
  Parent window id: 0x0 (none)
     103 children:
     0x2c0005c (has no name): ()  1x1+0+0  +0+0
     0x2c0005b (has no name): ()  1x1+0+0  +0+0
     0x2c0005a (has no name): ()  1x1+0+0  +0+0
     0x2c00059 (has no name): ()  1x1+0+0  +0+0
     0x2c00058 (has no name): ()  1x1+0+0  +0+0
     0x2c00057 (has no name): ()  1x1+0+0  +0+0
     0x2c00056 (has no name): ()  1x1+0+0  +0+0
     0x2c00055 (has no name): ()  1x1+0+0  +0+0
     0x2c00054 (has no name): ()  1x1+0+0  +0+0
     0x2c00053 (has no name): ()  1x1+0+0  +0+0
     0x2c00052 (has no name): ()  1x1+0+0  +0+0
     0x2c0004f (has no name): ()  1x1+0+0  +0+0
     0x2c0004e (has no name): ()  1x1+0+0  +0+0
     0x2c0004d (has no name): ()  1x1+0+0  +0+0
     0x2c0004c (has no name): ()  1x1+0+0  +0+0
     0x2c00047 (has no name): ()  1x1+0+0  +0+0
     0x2c00046 (has no name): ()  1x1+0+0  +0+0
     0x2c00045 (has no name): ()  1x1+0+0  +0+0
     0x2c00044 (has no name): ()  1x1+0+0  +0+0
     0x2c00043 (has no name): ()  1x1+0+0  +0+0
     0x2c00040 (has no name): ()  1x1+0+0  +0+0
     0x2c0003c (has no name): ()  1x1+0+0  +0+0
     0x2c0003b (has no name): ()  1x1+0+0  +0+0
     0x2c0003a (has no name): ()  1x1+0+0  +0+0
     0x2c00039 (has no name): ()  1x1+0+0  +0+0
     0x2c00031 (has no name): ()  1x1+0+0  +0+0
     0x2c0002c (has no name): ()  1x1+0+0  +0+0
     0x2c0002b (has no name): ()  1x1+0+0  +0+0
     0x2c0002a (has no name): ()  1x1+0+0  +0+0
     0x2c00029 (has no name): ()  1x1+0+0  +0+0
     0x2c00028 (has no name): ()  1x1+0+0  +0+0
     0x2c00027 (has no name): ()  1x1+0+0  +0+0
     0x2c00026 (has no name): ()  1x1+0+0  +0+0
     0x2c00025 (has no name): ()  1x1+0+0  +0+0
     0x2c00024 (has no name): ()  1x1+0+0  +0+0
     0x2c00023 (has no name): ()  1x1+0+0  +0+0
     0x2c00022 (has no name): ()  1x1+0+0  +0+0
     0x2c0001f (has no name): ()  1x1+0+0  +0+0
     0x2c0001e (has no name): ()  1x1+0+0  +0+0
     0x2c0001d (has no name): ()  1x1+0+0  +0+0
     0x2c0001c (has no name): ()  1x1+0+0  +0+0
     0x2c0001b (has no name): ()  1x1+0+0  +0+0

    etc.

[wez]

Please try the latest nightly build; I think this is due to an issue with the IME support that has been fixed in main.

[fedxyz]

Hi @wez , I tested it with 20250503-070428-474ad16e and it's not solved, but for sure the issue is caused by ime. Every time I launch a terminal it creates a (has no name): () 1x1+0+0 +0+0 as you can see in this log, every time I launched and closed a terminal:

     0x60001f (has no name): ()  1x1+0+0  +0+0
     0x60001e (has no name): ()  1x1+0+0  +0+0
     0x60001d (has no name): ()  1x1+0+0  +0+0
     0x60001c (has no name): ()  1x1+0+0  +0+0
     0x60001b (has no name): ()  1x1+0+0  +0+0
     0x60001a (has no name): ()  1x1+0+0  +0+0
     0x600019 (has no name): ()  1x1+0+0  +0+0
     0x600018 (has no name): ()  1x1+0+0  +0+0
     0x600017 (has no name): ()  1x1+0+0  +0+0
     0x600016 (has no name): ()  1x1+0+0  +0+0
     0x600015 (has no name): ()  1x1+0+0  +0+0
     0x600014 (has no name): ()  1x1+0+0  +0+0
     0x600013 (has no name): ()  1x1+0+0  +0+0
     0x600012 (has no name): ()  1x1+0+0  +0+0
     0x600011 (has no name): ()  1x1+0+0  +0+0
     0x600010 (has no name): ()  1x1+0+0  +0+0
     0x60000f (has no name): ()  1x1+0+0  +0+0
     0x60000e (has no name): ()  1x1+0+0  +0+0
     0x60000d (has no name): ()  1x1+0+0  +0+0
     0x60000c (has no name): ()  1x1+0+0  +0+0
     0x60000b (has no name): ()  1x1+0+0  +0+0
     0x60000a (has no name): ()  1x1+0+0  +0+0
     0x600009 (has no name): ()  1x1+0+0  +0+0
     0x600008 (has no name): ()  1x1+0+0  +0+0
     0x600007 (has no name): ()  1x1+0+0  +0+0
    ....

and for sure it will creates it in other circumstance.

With config.use_ime = false it works, it still creates this 1x1+0+0 +0+0 but when I close the terminal it's removed.

[wez]

I'm not sure that we've identified correctly what you're experiencing. Under X11 wezterm will always try to establish a connection to the IME. The use_ime option just tells us whether we should try to route key events via the IME. We will continue to inform it of the changing cursor position regardless of the setting of the use_ime flag.

If use_ime = false fixes things for you, I'd like to understand what exactly it is fixing, because it doesn't change the nature or number of resources that wezterm will allocate, or when those will be released.

Going back to your original post: it sounds like you are spawning a fresh wezterm each time? That will use more resources per window overall because each will be a separate process. I'd recommend not using --always-new-process if you don't have a good reason to actively use it.

[fedxyz]

I try to clarify, sorry for the confusion.

When i reported the issue, my first post, I was not aware of what was the cause of why my system becomes slow, I was about sure from various tests it was related to wezterm so I posted the bug.

After some search I found the post I linked on pipcom issues list https://github.com/yshui/picom/issues/1289#issuecomment-2244149866 and I tried the command to monitor window/children number

watch -n 1 -- xwininfo -root -tree

and I noticed the same behaviour, not in the same circumstance, but very high number of window 1x1+0+0 +0+0 created by wezterm and that slows down the system (in some case there were like 3000+), here my second post/update.

I am not using --always-new-process anymore, this was at the time of my first post when, without knowing where the cause of the problem was, wezterm was giving me a warning on journal about this option (wezterm_gui > Spawned your command via the existing GUI instance. Use wezterm start --always-new-process... ) so I tried this too for testing. But to be clear in my last tests this option was not used.

The problem in practice is that wezterm will create and not remove 1x1+0+0 +0+0 windows and the number of these windows will grow indefinitely in time, if use_ime is active. I was seeing this launching wezterm and closing it (this to find a replicable way to see the issue), see it in my last post log, and other times with tmux and for sure it will happen in other circumstance that I didn't identify right now.

[pjm0616]

This is strange, because for me this specific issue(lots of 1x1 windows) has also disappeared after this issue has been resolved.

Just to be sure I tested wezterm again with an old version(without the fix) and the nightly version(with the fix):

1. Environment: Ubuntu 24.04 + X11 + awesome WM + IBus IME
2. I opened a terminal and ran this command to monitor the number of 1x1 windows: while sleep 1; do date; xwininfo -root -tree | grep 1x1 | wc -l; echo; done
3. I tested an old version without the fix: 20240203-110809-5046fc22 (downloaded from here) 1. check version: $ ./wezterm/usr/bin/wezterm --version -> wezterm 20240203-110809-5046fc22 2. start wezterm: $ ./wezterm/usr/bin/wezterm start --always-new-process 3. I moved the newly opened wezterm window a lot. 4. As I moved the wezterm window, the number of 1x1 windows continuously increased from 117 to 551. Note that this only happens when the IME init has failed on startup as noted in the issue above. 5. After I terminated wezterm most of the 1x1 windows still remain.
4. And then the nightly version: 20250504-063133-dd3caaae (downloaded from here) 1. check version: $ ./wezterm/usr/bin/wezterm --version -> wezterm 20250504-063133-dd3caaae 2. start wezterm: ./wezterm/usr/bin/wezterm start --always-new-process 3. The number of 1x1 windows increased from 555 to 556 then 557. 4. I moved the newly opened wezterm window a lot. 5. The number of 1x1 windows didn't increase even if the window is moved or I typed some text. 6. After I terminated wezterm the number of 1x1 windows decreased to 556. (not 555 - indicates that there are still some issues with cleanup)

[fedxyz]

Hi @digitallyserviced ,

I run wezterm via i3 using bindsym $mod+Return exec --no-startup-id wezterm , defined in i3's config and I close it with kill window command defined in i3 $mod+Shift+q.

I add some video as you requested in both of them use_ime is at its default value, the watch... command is run in a urxvt terminal. In the first one you can see that the 1x1 window are not removed it continues to increment: I am simply run/close wezterm.

About tmux I can't say what will cause the issue, I am not able to replicate the behaviour when I want: it happen after some time when I am using it and the cursor becomes very slow so I am sure something happened.

Now it doesn't happen anymore because I am keeping use_ime = false but maybe it is like @pjm0616 says: with the nightly version the issue is mostly resolved, bu there is still a cleanup issue.

Here is my .bashrc

case $- in
    *i*) ;;
      *) return;;
esac
HISTCONTROL=ignoreboth
shopt -s histappend
HISTSIZE=1000
HISTFILESIZE=2000
shopt -s checkwinsize
[ -x /usr/bin/lesspipe ] && eval "$(SHELL=/bin/sh lesspipe)"
if [ -z "${debian_chroot:-}" ] && [ -r /etc/debian_chroot ]; then
    debian_chroot=$(cat /etc/debian_chroot)
fi
case "$TERM" in
    xterm-color|*-256color|xterm-kitty|xterm-ghostty|alacritty) color_prompt=yes;;
esac
if [ -n "$force_color_prompt" ]; then
    if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then
	color_prompt=yes
    else
	color_prompt=
    fi
fi
if [ "$color_prompt" = yes ]; then
    PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
else
    PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
fi
unset color_prompt force_color_prompt
case "$TERM" in
xterm*|rxvt*)
    PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a\]$PS1"
    ;;
*)
    ;;
esac
if [ -x /usr/bin/dircolors ]; then
    test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval "$(dircolors -b)"
    alias ls='ls --color=auto'
    alias grep='grep --color=auto'
    alias fgrep='fgrep --color=auto'
    alias egrep='egrep --color=auto'
fi
alias ll='ls -alF'
alias la='ls -A'
alias l='ls -CF'
alias alert='notify-send --urgency=low -i "$([ $? = 0 ] && echo terminal || echo error)" "$(history|tail -n1|sed -e '\''s/^\s*[0-9]\+\s*//;s/[;&|]\s*alert$//'\'')"'
if [ -f ~/.bash_aliases ]; then
    . ~/.bash_aliases
fi
if ! shopt -oq posix; then
  if [ -f /usr/share/bash-completion/bash_completion ]; then
    . /usr/share/bash-completion/bash_completion
  elif [ -f /etc/bash_completion ]; then
    . /etc/bash_completion
  fi
fi
vicd()
{
    local dst="$(command vifm --choose-dir - "$@")"
    if [ -z "$dst" ]; then
        echo 'Directory picking cancelled/failed'
        return 1
    fi
    cd "$dst"
}
fcd() {
    local dir
    dir=$(fdfind . --type d --exclude .git "$@" | fzf)
    [[ -d $dir ]] || return ; cd -- "$dir"
}
export GROOVY_TURN_OFF_JAVA_WARNINGS=true
export PATH=$PATH:"$HOME/adb-fastboot/platform-tools/"
alias pandock='docker run --rm -v "$(pwd):/data" -u $(id -u):$(id -g) pandoc/extra'
export FZF_DEFAULT_COMMAND='fdfind . --hidden --exclude ".git"'
alias p1='fcd ~/projects1/'
alias p2='fcd ~/projects2/'
PS1='\[\e[0;2m\]\$ \[\e[0;1m\]\w \[\e[0;1m\]> \[\e[0m\]'
export SDKMAN_DIR="$HOME/.sdkman"
[[ -s "$HOME/.sdkman/bin/sdkman-init.sh" ]] && source "$HOME/.sdkman/bin/sdkman-init.sh"

[fedxyz]

@digitallyserviced ok ! I didn't mention in my last post but just to be clear I am running wezterm 20250503-070428-474ad16e

[SASILOXR]

Hi, @fedxyz I did some tests with fcitx5, and I found that wezterm does not frequently generate 1x1 windows under fcitx5, and st has the same behavior as you, but it does not remain. The problem is probably related to ibus.

In addition, I can clean up these 1x1 windows by reloading i3 under fcitx5. If you must use ime but are worried about these windows affecting performance, you can try

my wezterm version: wezterm 20250511-222309-475e9f57

[fedxyz]

Hi @SASILOXR , I did some test with wezterm 20250514-071422-909573fa (sorry this is not your version but this is the last nightly that I can install via apt) and the cleanup problem with 1x1 windows is still there, the behaviour has not changed.

I have to say that in my case reloading i3 will decrease 1x1 windows but will not clean all of them, indeed number of children will not reset to the number of children before running wezterm.

While disabling ime via config.use_ime = false I have no problems.

In my case, I don't have to use IME, and I didn't know about it before I found this issue with WezTerm while reading about it in the issue mentioned earlier on the Picom issues list.

[github-actions[bot]]

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.

[fedxyz]

Hi @SASILOXR , @wez

he issue has been erroneously marked as stale and automatically closed. I responded by providing information two weeks ago, I thought it would be sufficient. If you need any additional information, please let me know.

[haltingstate]

I am experiencing this issue also. After running several hours on OSX, terminal becomes very slow to respond.

[kaddkaka]

I have similar issue on Xubuntu (Ubuntu + xfce + lighdm(I think)) with wezterm version 20241015-083151-9ddca7bd. I see huge CPU usage form the Xorg process, usually after resizing my wezterm vertically split pane with my mouse.

(I usually run this layout:)

         |
terminal |   nvim
         |

I tried to use xrestop to figure out the problems, but the only thing I could see where some <unknown> with a big number in the Wins column. https://linux.die.net/man/1/xrestop