100% processor useage when selecting zsh as startup shell

[darius]

guake 0.4.0 on ubuntu karmic. When I start guake with default shell, and then enter into zsh, it works as expected. when I switch to use zsh, I get 100% cpu, partly form x and form guake. no error messages when I startup guake from commandline. guake window is there, but does not stay in frot, just flashes.

[pingou]

Could you give it a try with Guake 0.4.1 ?

[darius]

yes, same behaviour with 0.4.1. sadly. happens when I try /bin/zsh /bin/ksh /bin/csh /usr/bin/csh /usr/bin/screen /bin/false

[dmartinezc]

¿do you have thous shells installed properly? i don't XD but they don't appears in the list.... in the particular case of screen, that shell should be started within the default shell instead as a normal shell (i suppose), in that case (when screen is selected) when you start guake screen is a zombie process so i suppose that the CPU overhead is because a busy waiting, guake may be waiting for screen to start while screen is already killed.

that's all I can help, i'm not a python programmer. (i'm a C one but really newy)

greetings

[Soulsuke]

I run guake 0.4.1 with zsh on OpenSolaris? without any problems... Could this be a copy of/related with another bug regarding Ubuntu Karmic? (this one: http://guake.org/ticket/192 )

[lincoln]

Is this bug in some way related to the #192 one?

[nimms]

I get the same problem on Ubuntu Lucid. With either 4.1.2 from the ubuntu apt-repo or when compiling it from source.

[Oren_Held]

A few more findings: * still happens on 0.4.2 * The same bug (X + Python processes high cpu load) happens also without bash, and the shell-switching trick doesn't work for me. * Python profiler showed that gtk.main() is the cpu-consuming function call. * Doesn't happen on my desktop (AMD x86), does happen on my laptop (Intel x86_64). Both have the exact same Debian Sid version, thus same X, gtk, etc. Only very different hardware.

If you have ideas on how I can debug it further (I got stuck after the profiling step) I'll be glad to.

[sylvestre]

For information, I get a feedback from two users that a recent update of some dependencies has fixed the issue. Unfortunately, I don't have any information about the impacted package...

CF:  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=593917#32