>>>>> "Troy" == Troy Daniels <[EMAIL PROTECTED]> writes:

  Troy> Hello,

  Troy> My emacs has recently started to occasionally freeze for a
  Troy> minute or so, using the entire CPU.  For example, hasn't
  Troy> updated in the screen in the minute since I did M-x
  Troy> jde-ant-build.  This might be a problem with JDE, but it also
  Troy> might be some other package I'm running or an interaction
  Troy> between them.


  Troy> When this happens, is there a good way to figure out what
  Troy> emacs is doing?  I did recently update to the latest JDE, but
  Troy> I reverted to my previous version when I saw that the debugger
  Troy> didn't work in the latest beta.  Other than that, I haven't
  Troy> changed my environment recently.



Turn on the "Enter debugger on Quit/C-g" in the options menu. 
When emacs eats your CPU hit ctrl-g and you get a stack trace. You
might need to do this several times; if you have something running on
a timer it might not be running at exactly the point that you hit ctrl-g

For example run...

(defun test()
        (interactive)
        (while t))

and ctrl-g gives you...

Debugger entered--Lisp error: (quit)
  (while t)
  test()
* call-interactively(test)
  execute-extended-command(nil)
  call-interactively(execute-extended-command)


For what it's worth, I've found that font-lock is the usual culprit,
particularly if you have the maximum buffer size set high. 

Failing this you need to run emacs under a gdb. This is only any use
if you are reasonably familiar with gdb and Emacs.

Cheers

Phil

Reply via email to