for loop zsh parse error 100% cpu
hi
im using grml-etc-core on a bit outdated debian box. and when executing the following cpu goes to 100% and i have to kill -9 zsh.
for i in 1 2 3; do zsh: parse error
i think it came up when i upgraded grml-etc-core to unstable. which version is in stable?
$ cat /etc/issue Debian GNU/Linux 3.1 \n \l
$ apt-cache policy grml-etc-core zsh grml-etc-core: Installed: 0.3.56 Candidate: 0.3.56 Version Table: *** 0.3.56 0 500 http://deb.grml.org grml-testing/main Packages 100 /var/lib/dpkg/status zsh: Installed: 4.2.5-7 Candidate: 4.2.5-7 Version Table: 4.3.2-13bpo1 0 200 http://www.backports.org sarge-backports/main Packages *** 4.2.5-7 0 500 http://ftp.at.debian.org sarge/main Packages 100 /var/lib/dpkg/status
* Matthias Merk macem99@gmail.com [20080911 08:31]:
im using grml-etc-core on a bit outdated debian box. and when executing the following cpu goes to 100% and i have to kill -9 zsh.
for i in 1 2 3; do zsh: parse error
i think it came up when i upgraded grml-etc-core to unstable. which version is in stable?
% acp grml-etc-core grml-etc-core: Installed: 0.3.56 Candidate: 0.3.56 Version table: *** 0.3.56 0 996 http://deb.grml.org grml-testing/main Packages 100 /var/lib/dpkg/status 0.3.49 0 996 http://deb.grml.org grml-stable/main Packages
$ apt-cache policy grml-etc-core zsh grml-etc-core: Installed: 0.3.56 Candidate: 0.3.56 Version Table: *** 0.3.56 0 500 http://deb.grml.org grml-testing/main Packages 100 /var/lib/dpkg/status
Why do you use grml-testing without using grml-stable as well? :)
zsh: Installed: 4.2.5-7 Candidate: 4.2.5-7 Version Table: 4.3.2-13bpo1 0 200 http://www.backports.org sarge-backports/main Packages *** 4.2.5-7 0 500 http://ftp.at.debian.org sarge/main Packages 100 /var/lib/dpkg/status
Ah, pretty old box. :)
I can't reproduce the problem with zsh 4.3.6 (i686-pc-linux-gnu) and latest grml-etc-core.
Does it happen with 'zsh -f' as well?
Can you please try to downgrade to an older grml-etc-core version so we can locate the problem easier?
If you have mercurial (hg) and Debian's build stuff available you can build all the different versions on your own:
hg clone http://hg.grml.org/grml-etc-core cd grml-etc-core hg up $VERSION # where VERSION is just a tag in hg, just use the # grml-etc-core version you'd like to get debuild -us -uc
If that's not an option for you let me know and we will provide different debian packages for you.
@Frank: do you have any idea where this might come from?
regards, -mika-
On Thu, Sep 11, 2008 at 9:44 AM, Michael Prokop mika@grml.org wrote:
- Matthias Merk macem99@gmail.com [20080911 08:31]:
im using grml-etc-core on a bit outdated debian box. and when executing the following cpu goes to 100% and i have to kill -9 zsh.
for i in 1 2 3; do zsh: parse error
i think it came up when i upgraded grml-etc-core to unstable. which version is in stable?
% acp grml-etc-core grml-etc-core: Installed: 0.3.56 Candidate: 0.3.56 Version table: *** 0.3.56 0 996 http://deb.grml.org grml-testing/main Packages 100 /var/lib/dpkg/status 0.3.49 0 996 http://deb.grml.org grml-stable/main Packages
$ apt-cache policy grml-etc-core zsh grml-etc-core: Installed: 0.3.56 Candidate: 0.3.56 Version Table: *** 0.3.56 0 500 http://deb.grml.org grml-testing/main Packages 100 /var/lib/dpkg/status
Why do you use grml-testing without using grml-stable as well? :)
i commented out stable five minutes ago :)
zsh: Installed: 4.2.5-7 Candidate: 4.2.5-7 Version Table: 4.3.2-13bpo1 0 200 http://www.backports.org sarge-backports/main Packages *** 4.2.5-7 0 500 http://ftp.at.debian.org sarge/main Packages 100 /var/lib/dpkg/status
Ah, pretty old box. :)
I can't reproduce the problem with zsh 4.3.6 (i686-pc-linux-gnu) and latest grml-etc-core.
Does it happen with 'zsh -f' as well?
Yes!
Can you please try to downgrade to an older grml-etc-core version so we can locate the problem easier?
If you have mercurial (hg) and Debian's build stuff available you can build all the different versions on your own:
hg clone http://hg.grml.org/grml-etc-core cd grml-etc-core hg up $VERSION # where VERSION is just a tag in hg, just use the # grml-etc-core version you'd like to get debuild -us -uc
If that's not an option for you let me know and we will provide different debian packages for you.
@Frank: do you have any idea where this might come from?
it breaks with 0.3.52 where the vcs prompt stuff was introduced ( http://hg.grml.org/grml-etc-core/rev/1331f322ab7e ) thats why i upgraded actually ;)
maybe i neeed a newer version of zsh!?
thanks for the help!
* Matthias Merk macem99@gmail.com [20080911 11:01]:
On Thu, Sep 11, 2008 at 9:44 AM, Michael Prokop mika@grml.org wrote:
- Matthias Merk macem99@gmail.com [20080911 08:31]:
Can you please try to downgrade to an older grml-etc-core version so we can locate the problem easier?
[...]
it breaks with 0.3.52 where the vcs prompt stuff was introduced ( http://hg.grml.org/grml-etc-core/rev/1331f322ab7e ) thats why i upgraded actually ;)
Ah interesting, thanks for locating.
maybe i neeed a newer version of zsh!?
Looks so, but we should update the configuration as well so it works flawless with older zsh versions as well. :)
* Matthias Merk macem99@gmail.com [20080911 11:02]:
Does it happen with 'zsh -f' as well?
Yes!
i meant 'NO!' of course. it works with 'zsh -f'!
Alright, so definitely some kind of problem in our config.
@Frank: care to investigate on that?
regards, -mika-
Michael Prokop mika@grml.org: [...]
i meant 'NO!' of course. it works with 'zsh -f'!
Alright, so definitely some kind of problem in our config.
@Frank: care to investigate on that?
Yes, I already tried it.
Given the code that introduces the bug:
[snip] for i in 1 2 3; do zsh: parse error [snap]
Clearly hints to something in our configuration, because that's pretty basic zsh syntax. However, I'm not sure the vcs_info() stuff is responsible here.
I can reproduce the problem with grml's config (even though on my box zsh does _not_ eat 100% CPU after that).
If I *disable* the vcs_info() code by: % zstyle 'vcs_info:*:' enable false
I _still_ get the parse error.
I cannot reproduce this with my own configuration - from which I cut'n'pasted the vcs_info() code into the grml setup. That means, I'm using the same code in my config.
I do have a suspicion, where the problem may be located.
Matthias, does this still happen for you after disabling vcs_info(): zstyle 'vcs_info:*:' enable false
I suspect you can and I'm looking at my suspicion right now.
Regards, Frank
Frank Terbeck ft@grml.org:
Michael Prokop mika@grml.org: [...]
i meant 'NO!' of course. it works with 'zsh -f'!
Alright, so definitely some kind of problem in our config.
@Frank: care to investigate on that?
[...]
[snip] for i in 1 2 3; do zsh: parse error [snap]
[...]
I do have a suspicion, where the problem may be located.
My suspicion was correct, this should fix it (+a few cleanups): http://hg.grml.org/grml-etc-core/rev/9ef02f6cf89f
Thanks for reporting!
Regards, Frank
* Frank Terbeck ft@grml.org [20080911 12:10]:
Frank Terbeck ft@grml.org:
Michael Prokop mika@grml.org:
@Frank: care to investigate on that?
I do have a suspicion, where the problem may be located.
My suspicion was correct, this should fix it (+a few cleanups): http://hg.grml.org/grml-etc-core/rev/9ef02f6cf89f
Package grml-etc-core version 0.3.57 is available in grml-testing and works fine for us, thanks - Frank.
Matthias, can you please let us know whether it fixes your issue as well?
regards, -mika-
On Thu, Sep 11, 2008 at 12:16 PM, Michael Prokop mika@grml.org wrote:
- Frank Terbeck ft@grml.org [20080911 12:10]:
Frank Terbeck ft@grml.org:
Michael Prokop mika@grml.org:
@Frank: care to investigate on that?
I do have a suspicion, where the problem may be located.
My suspicion was correct, this should fix it (+a few cleanups): http://hg.grml.org/grml-etc-core/rev/9ef02f6cf89f
Package grml-etc-core version 0.3.57 is available in grml-testing and works fine for us, thanks - Frank.
Matthias, can you please let us know whether it fixes your issue as well?
0.3.57 works. Thanks much Frank and Michael!
matthias
participants (3)
-
Frank Terbeck -
Matthias Merk -
Michael Prokop