High CPU load after pressing arbitrary key (mostly in C mode)

High CPU load after pressing arbitrary key (mostly in C mode)

[Michal Sojka]

Hi all,

I experience a weird a problem. It appears more or less randomly,
typically after using emacs for several hours. The responsiveness of emacs
starts to be very slow. Whenever I press a key, for example to type some
character, it appears on the screen in let say half a second. By
pressing several keys fast, the CPU load goes to 100%.

This happens mostly in C mode. By switching to another mode, the
response is better but occasionally there is a long delay even in the
other modes.

I workaround this by exiting emacs and starting it again. Is there any
way how to debug such problems. For example tracing all functions that
are called when a key is pressed?

I tried to switch off font-lock-mode, but it didn't change anything.

My emacs is:
GNU Emacs 23.3.1 (x86_64-pc-linux-gnu, GTK+ Version 2.24.4), Debian.

Thanks,
Michal

Re: High CPU load after pressing arbitrary key (mostly in C mode)

[suvayu ali]

On Wed, Aug 17, 2011 at 5:56 PM, Michal Sojka
<sojka@os.inf.tu-dresden.de> wrote:
> I workaround this by exiting emacs and starting it again. Is there any
> way how to debug such problems. For example tracing all functions that
> are called when a key is pressed?
>

My lisp know-how is not that great. However AFAIU, you can toggle debug on
quit and debug on error. Then when the slow down happens, press any
key and as the CPU load goes up hit quit (C-g). If that triggers the
debugger you could get some hints from there.

GL.

-- 
Suvayu

Open source is the future. It sets us free.

Re: High CPU load after pressing arbitrary key (mostly in C mode)

[Michal Sojka]

On 08/18/2011 01:59 PM, suvayu ali wrote:
> On Wed, Aug 17, 2011 at 5:56 PM, Michal Sojka
> <sojka@os.inf.tu-dresden.de>  wrote:
>> I workaround this by exiting emacs and starting it again. Is there any
>> way how to debug such problems. For example tracing all functions that
>> are called when a key is pressed?
>>
> My lisp know-how is not that great. However AFAIU, you can toggle debug on
> quit and debug on error. Then when the slow down happens, press any
> key and as the CPU load goes up hit quit (C-g). If that triggers the
> debugger you could get some hints from there.
Thanks for reply. I have tried this, but the backtrace was almost empty every time. It seems that C-g was processed only after the previous keys, which caused the load, were processed :-(

-Michal

Re: High CPU load after pressing arbitrary key (mostly in C mode)

[suvayu ali]

On Thu, Aug 18, 2011 at 2:08 PM, Michal Sojka
<sojka@os.inf.tu-dresden.de> wrote:
> Thanks for reply. I have tried this, but the backtrace was almost empty
> every time. It seems that C-g was processed only after the previous keys,
> which caused the load, were processed :-(
>

In that case if you can replicate this with emacs -Q, its bug report time. :)

> -Michal
>

GL.

-- 
Suvayu

Open source is the future. It sets us free.

Re: High CPU load after pressing arbitrary key (mostly in C mode)

[Michal Sojka]

On 08/18/2011 02:17 PM, suvayu ali wrote:
> On Thu, Aug 18, 2011 at 2:08 PM, Michal Sojka
> <sojka@os.inf.tu-dresden.de>  wrote:
>> Thanks for reply. I have tried this, but the backtrace was almost empty
>> every time. It seems that C-g was processed only after the previous keys,
>> which caused the load, were processed :-(
>>
> In that case if you can replicate this with emacs -Q, its bug report time. :)
Hmm, but the problem appears usually after emacs runs for several hours 
and using emacs for so long without my configuration would make me crazy :-(

-Michal

Re: High CPU load after pressing arbitrary key (mostly in C mode)

[suvayu ali]

On Thu, Aug 18, 2011 at 2:43 PM, Michal Sojka
<sojka@os.inf.tu-dresden.de> wrote:
> Hmm, but the problem appears usually after emacs runs for several hours and
> using emacs for so long without my configuration would make me crazy :-(

Yes I realised that after I hit send. Maybe you could try a binary
search on your config. I realise this will take days to figure out.
But probably worth it.

Of course the other solution to use a newer version of emacs (e.g. BZR trunk).

-- 
Suvayu

Open source is the future. It sets us free.

Re: High CPU load after pressing arbitrary key (mostly in C mode)

[Michael Heerdegen]

Hi,

just guessing: such an effect can be caused by settings that cause
frequent updating of the mode-line, like setting `display-time-interval'
to 1 or so.  Every redisplay of the mode-line causes the global menu
structure to be recalculated.  Do you define own menus?


Michael.

Re: High CPU load after pressing arbitrary key (mostly in C mode)

[Ian Zimmerman]

Michal> Hi all, I experience a weird a problem. It appears more or less
Michal> randomly, typically after using emacs for several hours. The
Michal> responsiveness of emacs starts to be very slow. Whenever I press
Michal> a key, for example to type some character, it appears on the
Michal> screen in let say half a second. By pressing several keys fast,
Michal> the CPU load goes to 100%.

Maybe you're using a mode that doesn't properly clean after itself,
for instance doesn't set markers to nil?

-- 
Ian Zimmerman
gpg public key: 1024D/C6FF61AD
fingerprint: 66DC D68F 5C1B 4D71 2EE5  BD03 8A00 786C C6FF 61AD
Rule 420: All persons more than eight miles high to leave the court.

Re: High CPU load after pressing arbitrary key (mostly in C mode)

[Michal Sojka]

On Fri, 19 Aug 2011, Ian Zimmerman wrote:
> 
> Michal> Hi all, I experience a weird a problem. It appears more or less
> Michal> randomly, typically after using emacs for several hours. The
> Michal> responsiveness of emacs starts to be very slow. Whenever I press
> Michal> a key, for example to type some character, it appears on the
> Michal> screen in let say half a second. By pressing several keys fast,
> Michal> the CPU load goes to 100%.
> 
> Maybe you're using a mode that doesn't properly clean after itself,
> for instance doesn't set markers to nil?

This sounds like a useful tip, thanks. I'll try to check for markers
when the problem appears again.

-Michal