quiescent zsh using pure occasionally jumps to 99% cpu usage #502
Comments
It happened in my active shell today.
It does. Here's are the most popular lines in ltrace: zsh_at_99_cpu_ltrace.txt is a small chunk of ltrace output. |
|
Thanks for reporting and for the trace @skierpage, I've seen this myself a few times and have not had time to dig into the issue. I've chucked it up to the IIRC, it's the async worker (i.e. zpty clone from the current shell) that is causing 99% CPU, which could indicate for example that the fd has become corrupt and the read-loop in the worker just keeps on looping without reaching the exit state. |
|
I'm having a similar problem but with a git repo, using It does seem to be |
|
Thanks @ixil. If either of you are able to reproduce the issue semi-reliably, I'd be very interested to know if this: https://github.com/mafredri/zsh-async/blob/95c2b1577f455728ec01cec001a86c216d0af2bd/async.zsh#L155 is where we're failing. The thing I'm most curious about is if this loop keeps spinning without pause, causing the cpu usage. Perhaps the |
|
Attaching ltrace to an unresponsive zsh in a git repo I get the below: Furthermore looking at a strace output which comes in longer (repeating blocks) that request keeps getting extended with values of the previous request |
|
I suspect my problem is not related as manually git fetching my repo spewed several thousand lines and then tried to download the repo - I think the read loop to find the null byte may have just been slowing it down. As far as I could see the problem for me was in rather than in with your read statement (at least throwing echos everywhere made it look like that |
The two ltrace()s I captured were nothing like that, no large repeating
That is like an strace I captured, , except I didn't see your read()/select() part at the end. |
Only fetch information for the current branch to minimize the amount of work Pure (well, git) needs to do. This commit also starts redirecting git stderr to `/dev/null` because in some cases git can start spewing errors like crazy (see #502). We also never use the stderr so there's no point in keeping it around. Fixes #473.
|
Perhaps it's this bug? Can anyone here check whether the issue reproduces after applying the linked patch? Here's how you can build zsh from HEAD on Debian-based Linux distro and install it as (
emulate -L zsh
setopt err_return
sudo apt update
sudo apt install -y git build-essential libncurses-dev gcc autoconf man yodl
zsh_dir="$(mktemp -d)"
{
git clone https://github.com/zsh-users/zsh $zsh_dir
cd $zsh_dir
./Util/preconfig
./configure
sudo make -j 20 install
} always {
sudo rm -rf $zsh_dir
}
)(Your original zsh is still available as Add grep -qE '^/usr/local/bin/zsh$' /etc/shells || sudo tee -a /etc/shells <<</usr/local/bin/zsh >/dev/nullMake chsh -s /usr/local/bin/zsh |
|
I’m experiencing this issue, and the following did not mitigate it:
I suppose the root cause stems from an old version of a package, somewhere (I use Ubuntu Focal). My system comes with Git |
|
Upgrading Git to version |
General information
I have:
Problem description
I run zsh as my default shell, and my terminal is Konsole with three tabs, one where I issue lots of commands and the other two mostly just showing output from programs I run (detached from the shell, they don't show up in
jobs). I installed pure in September 2018, I think it was a bit after version 1.8.0. Several times in 2019 I notice in top and htop output that zsh is at 99% CPU.psreveals the zsh at high usage is not in my active shell but one of these inactive ones. This high CPU is not turning the fan on so I'm usually not aware of it, and I'm not sure what triggers this high CPU mode. zsh is not in a git directory. I ranltraceand noticed someoutput, and pure uses this string, hence this bug report.
I just updated pure to latest version and instructions (adding it to fpath). After source ~/.zshrc in the pty that was at high CPU, the issue persisted, I will see if this recurs in new shells.
Reproduction steps
Don't know yet. I've noticed the high CPU usage about 7 times.
I completely understand if you reject this bug report as unreproducible, Thanks for this nice software.
My
.zshrc:The text was updated successfully, but these errors were encountered: