git info eventually stops being updated

[caarlos0]

General information

• Pure version: master (commit c985b19)
• ZSH version: 5.6.2
• Terminal program & version: iTerm 3.2.6
• Operating system: macOS 10.14.2
• ZSH framework: antibody

I have:

• Tested with another terminal program and can reproduce the issue:
• Followed the Integration instructions for my framework

Problem description

When I'm using a terminal panel for some time (hours or days), changing branches and etc, eventually, git info stops updating... it shows the old branch, for example, branch1, even though I keep changing branches. The arrows indicating push/pull also are not shown.

If I open another terminal panel/tab on the same folder, everything works as expected.

Reproduction steps

Don't know... :/

My .zshrc:

Not sure what's needed because I'm not sure what's causing it, but, pure-related, here it is:

PURE_CMD_MAX_EXEC_TIME=1
PURE_PROMPT_SYMBOL="λ"

source /Users/carlos/Library/Caches/antibody/https-COLON--SLASH--SLASH-github.com-SLASH-mafredri-SLASH-zsh-async/async.plugin.zsh
fpath+=( /Users/carlos/Library/Caches/antibody/https-COLON--SLASH--SLASH-github.com-SLASH-mafredri-SLASH-zsh-async )
source /Users/carlos/Library/Caches/antibody/https-COLON--SLASH--SLASH-github.com-SLASH-sindresorhus-SLASH-pure/pure.plugin.zsh
fpath+=( /Users/carlos/Library/Caches/antibody/https-COLON--SLASH--SLASH-github.com-SLASH-sindresorhus-SLASH-pure )

---

IssueHunt Summary

mafredri has been rewarded.

Backers (Total: $80.00)

• issuehunt ($80.00)

Submitted pull Requests

• #543 Respawn Pure async worker on crash

---

Tips

• Checkout the Issuehunt explorer to discover more funded issues.
• Need some help from other developers? Add your repositories on IssueHunt to raise funds.

[mafredri]

Thanks for the report, I'll try to look into this later today. It's curious though, I have much the same setup, sans antibody. Can you list any other zsh plugins you might be using?

Also, what method of authentication do you use for Git? HTTPS? SSH? If SSH, do you use GPG, etc? Are you ever prompted for passwords in the terminal (or outside)?

If this happens to you again, the output from pstree -p $$ might help (brew install pstree).

And finally, if you don't mind, could you test out this PR #454?

The reason I suggest it is that if your issue is related to the zpty worker crashing, then the PR could help by allowing the worker to be restarted the next time you hit enter in the prompt.

[caarlos0]

pstree -p $$
ohh forgot to do that :( will do next time it happens

Can you list any other zsh plugins you might be using?

sure thing: https://github.com/caarlos0/dotfiles/blob/master/antibody/bundles.txt

Also, what method of authentication do you use for Git? HTTPS? SSH? If SSH, do you use GPG, etc? Are you ever prompted for passwords in the terminal (or outside)?

SSH. I use GPG to sign commits, yes. No, never get prompted for passwords...

And finally, if you don't mind, could you test out this PR #454?

Sure thing! Will just wait for it to happen again to get the pstree output :)

[caarlos0]

Happened again:

~/Code/goreleaser/goreleaser master*
λ pstree -p $$
-+= 00001 root /sbin/launchd
 \-+= 38530 carlos /Applications/iTerm.app/Contents/MacOS/iTerm2
   \-+= 59908 carlos /Applications/iTerm.app/Contents/MacOS/iTerm2 --server /usr/bin/login -fpl carlos /Applications/iTerm.app/Contents/MacOS/iTerm2 --launch_shell
     \-+= 59909 root /usr/bin/login -fpl carlos /Applications/iTerm.app/Contents/MacOS/iTerm2 --launch_shell
       \-+= 59910 carlos -zsh
         \-+= 71784 carlos pstree -p 59910
           \--- 71785 root ps -axwwo user,pid,ppid,pgid,command

[mafredri]

Interesting, it indeed looks like the async worker (zpty) has died, for some reason :/.

I just realized, since you're using antibody, you might already have been running part of the #454 PR (e.g. the zsh-async update, or master branch) which would've killed the worker in case of an error. The second part of #454 would allow the worker to re-start on next prompt.

One thing that stands out from your bundles.txt is zsh-autosuggestions. It has caused me some problems in the past. It also uses zpty but creates / destroys its instance constantly (vs. long-running instance in zsh-async). If you can try to reproduce with it disabled, that would be good info as well.

I'll have to get back to you on this after the holidays, have a great one!

[caarlos0]

yeah, no worries!

Wish you great holidays! Thanks for the great work!

[sandangel]

I have the same issue here. May I ask any update on this?

[mafredri]

@sandangel still requires more info, I haven't been able to reproduce the issue, at least not reliably. It has stopped working for me on a few rare occasions as well but usually in combination with something else failing too (e.g. zsh-fast-syntax-highlighting which also is async).

It's tricky, so any information you can provide will be helpful.

[sandangel]

Yeah, it rarely happens to me too and I had to kill the terminal. I don't know how to reproduce reliably too. Currently, I decided to move to alien-minimal, another prompt that uses zsh-async but was not happy with it like pure so I just come here to see if the issue was fixed.

[mafredri]

Curious, did you use alien-minimal long enough that you should've experienced the issue, if it was present?

[mafredri]

Also, another question: Are either of you working on a lot of things when it happens, with many terminals/tabs or processes open on the computer? One reason could be that resource limits are being hit preventing more processes from being spawned.

[sandangel]

I have just started using alien-minimal today.

Are either of you working on a lot of things when it happens, with many terminals/tabs or processes open on the computer? One reason could be that resource limits are being hit preventing more processes from being spawned.

Yes, I have about 5 tmux pane with 3 to 4 windows each pane. I'm working on about 3 or 4 repos at the same time.

[caarlos0]

Also, another question: Are either of you working on a lot of things when it happens, with many terminals/tabs or processes open on the computer? One reason could be that resource limits are being hit preventing more processes from being spawned.

yes, always have like 3+ iTerm tabs with several panels in each one..

[samuelmasuy]

I also run in the same issue regularly, I have to source my zsh config each time it happens.
Here is the list of plugins I use from oh-my-zsh:

plugins=(git tmux mvn tmuxinator docker osx kubectl go web-search zsh_reload z zsh-syntax-highlighting history-substring-search)

I usually have about 8 tmux windows.

[caarlos0]

z zsh-syntax-highlighting history-substring-search

not sure if helps on anything, but we have those plugins in common...

[mafredri]

Hmm, I use / or have used all three myself (albeit my own fork of z with flock:ing and I've recently moved to zsh fast-syntax-highlighting) so not sure if there's any clue in those.

Could you try changing this line:

https://github.com/mafredri/zsh-async/blob/98d32afcce8e328be86f381c529e951943e57d19/async.zsh#L71

to:

exec 2>>/tmp/async-error.log

?

Let me know if any errors appear in the log when the problem occurs.

[caarlos0]

sure, done it... will observe and report whatever I find :)

[ttamnedlog]

Just to add my two cents, I've been experiencing this for several months. I commented on a previous issue (#435 (comment)), but my experience was actually unrelated to that issue. @mafredri asked me to open a new issue to troubleshoot, but I got busy/forgot! I do apologize. But this time I'm sure my issue is the same as described here, ha.

I'm going to try changing the line above and see if I get any positive results. I won't forget to report back this time!

And if it's helpful, here's my setup for reference and a screenshot of the error happening (first the down arrow signifying upstream updates did not go away after a git pull, and changing out and back into the directory no longer shows it as a git repo/branch at all). Definitely see some plugins in common with the other users here.

• Pure version: 1.9.0
• NPM version: 6.6.0
• Git version: 2.20.1
• ZSH version: 5.6.2
• Terminal program & version: iTerm 3.2.6
• Operating system: macOS Sierra 10.14.2
• ZSH framework: oh-my-zsh (updated every week or two, or when prompted)
• oh-my-zsh pluings: git osx brew vagrant jump zsh-syntax-highlighting history-substring-search

[caarlos0]

Just had the issue here again, /tmp/async-error.log was empty...

[mafredri]

Dang :/, thanks for testing though.

I'll try to get back to this after my vacation (gone for a week). In the meanwhile, @ttamnedlog how easily can you reproduce the issue?

I think this is going to be a hard one to debug without being able to reproduce it myself. Any chance this would be reproducible e.g. in a Docker container?

In the meantime, some more logging might help narrow this down:

pure/pure.zsh

Line 391 in d5e14a3

print "$0: $@" >> /tmp/pure.log

https://github.com/mafredri/zsh-async/blob/98d32afcce8e328be86f381c529e951943e57d19/async.zsh#L308

print "$0: $@" >> /tmp/async.log

[samuelmasuy]

I thought I would report this, even if it has only been a day that I have switched to fast-syntax-highlighting. But I was not able to reproduce the bug. For reference, the bug used to appear very often on my end (every 30 minutes or so).

fast-syntax-highlighting is actually a pretty decent alternative to zsh-syntax-highlighting 🙇

[ttamnedlog]

I'll try to get back to this after my vacation (gone for a week). In the meanwhile, @ttamnedlog how easily can you reproduce the issue?

Not easily. Sadly, it's the same as described by @caarlos0. It happens seemingly randomly after hours of work. Some days it happens a few times a day, other days it doesn't happen at all. I'm sure my work habits vary from day to day but I can't pinpoint what I might have done on the days it occurs. A rough description of my work habits, in case you see anything helpful:

I don't use tmux on my machine (I do use it occasionally while in a remote terminal, but the remote doesn't have Pure anyway so none of that applies). I usually have two or three iTerm tabs open in different directories within a repo. And I often hop around to different repos. One tab is probably a task runner watching for file modifications and compiling assets. One tab is probably just the shell for system commands and certain git commands like switching branches and pushing and pulling. And one tab is usually in Vim. It's probably 50/50 whether or not I stage and commit from my iTerm tab at the shell or if I do it from within Vim using fugitive.

In the past, working this way, it wasn't abnormal for me to switch iTerm tabs and see that one Pure git status indicator was showing the wrong branch or status. That's not the issue being discussed here, just to clarify. I didn't consider that a bug; I wouldn't expect one iTerm tab to know what the other is doing anymore than I'm surprised when I trash a directory in Finder and then in iTerm try to cd .. out of it and can't, ha. Simply pressing return would refresh the shell prompt and the status indicator would be up-to-date and accurate.

The bug we're discussing here doesn't necessarily occur due to multiple tab tomfoolery. In the screenshot I posted, for example, that's not my repo, so I wasn't working in that directory or having multiple tabs of that directory open. I just hopped into the zsh-syntax-highlighting plugin directory, Pure async told me there were upstream changes, I run git pull, and async still says there are upstream changes. git status tells me everything's clean and up-to-date, but async is still inaccurate. I cd out of the repo and back in, to try and jog something loose perhaps, and now Pure async doesn't even see it as a repo anymore. Opening a new iTerm tab and going to this directory, everything works fine in the new tab.

Sorry this was so long! I hope it was helpful. I know this is difficult to nail down without some clearer steps to reproduce. Thanks for looking into it. I'll enable the additional logging you suggest and keep you posted!

[ezpuzz]

also had issue with zsh-syntax-highlighting and this problem.

[caarlos0]

I replaced zsh-syntax-highlighting with fast-syntax-highlight, still got the issue, but it's less frequent I think

[OliverJAsh]

I'm also running into this issue. Are there any steps I can follow to help you debug this?

[mafredri]

@OliverJAsh any information you can provide could be helpful. E.g what's been discussed here and reports of how often it happens, what you were doing at the time and if it's limited to some specific repo. Also versions of the software / operating system you are using (as above).

I haven't gotten around to try to debug this much further, it's tricky without a solid way to reproduce it. I wonder, is it only limited to macOS?

[mafredri]

PS. Zsh 5.7.1 is out, does it also happen on it?

[OliverJAsh]

how often it happens

Maybe every 1/2 hours or so.

versions of the software / operating system

iTerm 3.2.6
Zsh 5.6.2
macOS 10.14.2
pure-prompt 1.8.0

I will try with the latest version of Zsh (5.7.1).

I've also just tried pure-prompt to 1.9.0 so I will see if that helps.

[wooken]

alacritty 0.2.9
ZSH 5.7.1
pure-prompt 1.9.0 (manually pulled down 1.9.0 tag within the submodule)
ArchLinux
fzf 0.17.5 (in case it's related)
prezto
+autosuggestions
-syntax-highlighting (turned this off for a while to see if it would help. but it doesn't seem to)

What happens

When it happens, these effects are observed:

• branch information does not update. possibly the entirety of the first line of the prompt does not update
• ctrl-c needs to be hit twice in order to take effect

How often it happens

It happens very sporadically.
Sometimes it happens right when I open a new terminal and enter only a few commands.
Other times, it could be hours in between.

Thank you for the great work

This prompt is very nice and feels very snappy. Keep up the awesome work!

[mafredri]

@wooken thanks for the report!

• ctrl-c needs to be hit twice in order to take effect

This I believe could be related to autosuggestions. I've experienced it myself when using it. Here's my answer to cleaning up some of the zsh-asug behavior: modules/zsh-autosuggestions.zsh

• Stops zsh-asug from rewrapping all zle widgets on every prompt
• Disables async mode because the asug server (zpty worker) is re-created on every prompt (which can sometimes mess up other zpty workers, e.g. interfere with zsh-async)

If possible, I'd suggest that everyone here who uses zsh-autosuggestions and is experiencing the issue would try using the above method of loading it, see if it helps.

[camsteffen]

Does anyone know of a workaround without exiting zsh?

[mafredri]

Took a look at this again after a talk with @sindresorhus about it, he pointed out some commits that got me thinking... so, I've created two branches:

• issue-445-testfix1 - Moves things around and adds an extra guard in async
• issue-445-testfix2 - Reverts "Simplify async tasks by not passing $PWD (Simplify async tasks by not passing $PWD #430)"

Please, if you can reproduce, give them a try and report back!

[sindresorhus]

issue-445-testfix1 - Moves things around and adds an extra guard in async

I switched to use this branch after your comment and I don't get a branch at all. I'll try testfix2 next.

[mafredri]

I switched to use this branch after your comment and I don't get a branch at all. I'll try testfix2 next.

Oh, looks like I made a booboo, fixed testfix1 now.

[sindresorhus]

I can confirm that testfix2 also has the issue of Git info eventually stops being updated. I still need to test testfix1 more.

[sindresorhus]

The git dirty status * just got stuck when using testfix1. It stays there even when the branch is not dirty. Restarting the terminal app makes the * disappear.

[mafredri]

Thanks for testing Sindre, it really is the worst news I could've hoped for 😂😭. If not even testfix2 fixes it, we'll have to dig deep. I'll try to set some time aside this weekend to look at it further, but at least we've excluded a few possibilities.

[issuehunt-oss]

@mattpolito has cancelled funding for this issue.(Cancelled amount: $40.00) See it on IssueHunt

[mafredri]

I just ran into this on again (master branch), and it seems I was able to be able to bring back to life by doing:

prompt_pure_async_init=0; async_stop_worker prompt_pure

Can anybody else confirm this? It doesn't really provide clues to the underlying issue, but could help us work around it in the meantime.

[sindresorhus]

@mafredri I can confirm that running the above command brought it back to life.

[mafredri]

@sindresorhus thanks for confirming.

I've found what I believe to be the ~reason for this. Well, I can't explain why it happens, but at least where.

There's now a new PR open in zsh-async (mafredri/zsh-async#37) which addresses it and a few more improvements fueled by paranoia. I believe this is where we ran into trouble until now: mafredri/zsh-async#37/files#diff-c7f89cff42efffc19f69071441a12a1cR170-R174.

I've now created the indestructible-pure branch, which listens to the new signals from zsh-async and should allow for recovery on next prompt. I managed to trigger the issue a few times before making all of the above changes, but after I added the handling in Pure, I could no longer 😅.

Anyway, please try it out. Ideally, as a next step, I'd like to automatically detect worker crashes in zsh-async and do the restart there, but we'll see.

[esetnik]

Can anybody else confirm this? It doesn't really provide clues to the underlying issue, but could help us work around it in the meantime.

I just reproduced the issue on my local system and running the command prompt_pure_async_init=0; async_stop_worker prompt_pure fixed it for me.

[mayanksuman]

I think it is the problem with zsh-async. In prezto, themes that use zsh-asyc (such as pure, sorin) are showing occasional hang while in git directory. All other themes work fine. I also get unacceptable delay in deleting text if I have written wrong command (also happen when I am in git directory).

In my case the above stated workaround do not work.

Tested in zsh 5.7.1 (x86_64-debian-linux-gnu).

[wooken]

@mafredri been trying indestructible-pure branch the last few days and I have yet to run into git info issues or 100% CPU usage

[jlebar]

In case anyone runs into this problem: In switching to the indestructible-pure branch, I ran npm -g uninstall pure-prompt because I wanted to be sure I was using the git-cloned branch. After I did this, I started getting the following error message when I started a new terminal

Couldn't read file /usr/local/share/zsh/site-functions/prompt_pure_setup containing theme pure.

Turns out npm uninstall left a broken symlink with this name. Removing the broken symlink got rid of the error.

[esetnik]

@sindresorhus do you plan to release a new version with this fix?

[caarlos0]

would be awesome!

[mafredri]

Had some time last weekend to work on this and wrapped it up today, the final iteration of zsh-async and pure worker restarting is now in #543. Please, for anyone affected, give it a spin and report any issues here.

Workers can still crash, but restarts are completely transparent and should not result in any inconveniences for the user.

[mafredri]

Oh, might as well add this as well. So last weekend I automated triggering this bug, but it's by no means reliable and requires bruteforceing. Anyway, this is what I came up with (run in a terminal that is not iTerm):

Variant that hops between home and my local Pure repo, does not require iTerm to be in focus but produces a lot of noise.

while :; do
        for dir in ~ ~/Projects/Pure; do
                osascript -e '
                        tell application "iTerm"
                                tell current session of current window
                                        write text "cd '$dir'"
                                end tell
                        end tell
                '
        sleep 0.22
        done
done

Variant using dircycle from my zsh config (changes directory from directory stack via Ctrl+Shift+Arrow) but requires iTerm to be in focus at all times but produces no noise.

osascript -e 'activate application "iTerm"'
for i in {1..1000}; do
        for i in {1..31}; do
                osascript -e '
                        tell application "System Events"
                                key code 124 using {shift down, control down}
                        end tell
                '
                sleep 0.12
        done
        sleep 2.01
done

Sleeps are just randomly picked from whatever seems to trigger it occasionally.

[issuehunt-oss]

@sindresorhus has rewarded $72.00 to @mafredri. See it on IssueHunt

• 💰 Total deposit: $80.00
• 🎉 Repository reward(0%): $0.00
• 🔧 Service fee(10%): $8.00