>>>>> "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