help! Keep getting emacs locked up / not responding to c-g / having to kill process

help! Keep getting emacs locked up / not responding to c-g / having to kill process

[unfrostedpoptart]

This is related to my previous post about clearing the kill ring.  I have a frequent case, when running shell buffers, where selecting a lot of the buffer (could be thousands of lines) seems to lock up emacs.  Most of the time, one or more c-g hits will stop what it was doing and give me back control.  However, lately (including 15 minutes ago) I've been hitting this and c-g does nothing and ps shows emacs at around 95% cpu.  As this is a shared server, that doesn't make me popular with other users!

I end up having to kill the process. This really sucks since I had about a dozen shell buffers logged into  multiple servers and running long jobs that were all killed when I killed emacs.

Any suggestions on stopping this from happening in the first place and/or something stronger than c-g but short of killing emacs?

FYI, this is 24.3.something on REH 5.something.

Thanks!

 David

RE: help! Keep getting emacs locked up / not responding to c-g / having to kill process

[Drew Adams]

> This is related to my previous post about clearing the kill ring.  I have a
> frequent case, when running shell buffers, where selecting a lot of the
> buffer (could be thousands of lines) seems to lock up emacs.  Most of the
> time, one or more c-g hits will stop what it was doing and give me back
> control.  However, lately (including 15 minutes ago) I've been hitting this
> and c-g does nothing and ps shows emacs at around 95% cpu.  As this is a
> shared server, that doesn't make me popular with other users!
> 
> I end up having to kill the process. This really sucks since I had about a
> dozen shell buffers logged into  multiple servers and running long jobs that
> were all killed when I killed emacs.
> 
> Any suggestions on stopping this from happening in the first place and/or
> something stronger than c-g but short of killing emacs?
> 
> FYI, this is 24.3.something on REH 5.something.

The suggestion I have is, as usual when nothing is said about the setup,
try to reproduce the problem without your init file, i.e., starting from
`emacs -Q'.  If you can repro it that way then report the recipe here,
asking for possible suggestions.  Or if you think it is a bug, report it
via `M-x report-emacs-bug'.

If the problem does not occur when you start from `emacs -Q', then try to
narrow down your init file, to see what causes the problem.  Then post
what you find here, if it's not obvious at that point how to fix it.

You say that most of the time repeated C-g works, but sometimes it does
not.  Sounds like Emacs is in an infinite loop.  For that too, I would
first suspect code (loaded) from your init file.  (Infinite loops in
vanilla Emacs get reported and fixed very quickly.)

IOW, a recipe please, or at least some more, and more concrete, info.

Re: help! Keep getting emacs locked up / not responding to c-g / having to kill process

[Michael Heerdegen]

unfrostedpoptart <david@therogoffs.com> writes:

> However, lately (including 15 minutes ago) I've been hitting this and
> c-g does nothing and ps shows emacs at around 95% cpu.  As this is a
> shared server, that doesn't make me popular with other users!

As Drew mentioned, it's hard to guess who the culprit is without more
details (recipe).

Anyway, in Unices you can force Emacs into the debugger, even if not
responsive, by sending SIGUSR2:

  pkill -SIGUSR2 emacs

Using the debugger, you hopefully should be able to see where Emacs
loops.

Michael.

Re: help! Keep getting emacs locked up / not responding to c-g / having to kill process

[unfrostedpoptart]

On Thursday, October 3, 2013 8:44:22 AM UTC-7, Michael Heerdegen wrote:
> unfrostedpoptart <david@> writes:
> > However, lately (including 15 minutes ago) I've been hitting this and
> > c-g does nothing and ps shows emacs at around 95% cpu.  As this is a
> > shared server, that doesn't make me popular with other users!
> 
> As Drew mentioned, it's hard to guess who the culprit is without more details (recipe).
> Anyway, in Unices you can force Emacs into the debugger, even if not
> responsive, by sending SIGUSR2:
> 
>   pkill -SIGUSR2 emacs
> Using the debugger, you hopefully should be able to see where Emacs loops.

Thanks guys!  I ran kill -l to look for something like Michael just suggested but didn't know what the different signals meant.  I'll try this.

Also, I'll try a big cleanup of my init.el.  It's been evolving for over 20 years since 18.57!  Every new emacs release, I try and clean it up some for deprecated functions and code that's not needed anymore because of new, built-in functions.  I know I have a lot of ugly stuff related to shell-mode and I'l see if I can remove most of it.

 David

Re: help! Keep getting emacs locked up / not responding to c-g / having to kill process

[unfrostedpoptart]

On Thursday, October 3, 2013 8:44:22 AM UTC-7, Michael Heerdegen wrote:

> Anyway, in Unices you can force Emacs into the debugger, even if not responsive, by sending SIGUSR2:
> 
>   pkill -SIGUSR2 emacs
>  
> Using the debugger, you hopefully should be able to see where Emacs loops.

I'm hitting this right now.  In this case, it was triggered by opening a PDF file.  It started rendering but apparently hung up somewhere.  

Running pkill -SIGUSR2 did eventually appear to get control back and displayed the backtrace buffer but when I'd try and do anything, it would lock up again.  After several pkills, I was able to get a buffer list and kill the PDF buffer.

I'm not really up on using backtrace, but FYI, here's what it says:

Debugger entered--entering a function:
* linum-update-current()
  recursive-edit()
  debug(error (quit))
  redisplay_internal\ \(C\ function\)()


Not sure if there's anything I can do now to help trace it but if there is, please let me know.

 David

Re: help! Keep getting emacs locked up / not responding to c-g / having to kill process

[Stefan Monnier]

> Debugger entered--entering a function:
> * linum-update-current()
>   recursive-edit()
>   debug(error (quit))
>   redisplay_internal\ \(C\ function\)()

> Not sure if there's anything I can do now to help trace it but if there is, please let me know.

I recommend you use nlinum-mode instead of linum-mode.  It might of
course suffer from the same problem, but it does suffer from fewer
problems, so maybe you'll get lucky.


        Stefan