On 12/24/2011 08:52 AM, Richard Kim wrote:
> In general I think idle timer must be very conservative in that it
> should do no harm. One of the reasons why it took me so long to get
> back to using semantic (my laziness being the foremost reason) is that
> each time I tried it over the years, my emacs somehow got hosed and it
> was difficult for me to figure out what was going on. Even now I turn
> off semantic sometimes, because my emacs just becomes so sluggish and
> quite often it does not respond to repeated control-g. I've been trying
> to obtain stack trace of such problems, but emacs is so hosed that I
> just kill it altogether. I will continue to try to help diagnose idle
> timer problems in the future. Tips on how to do that would be helpful,
> because I only know very old methods such as debug-on-error
> and debug-on-quit which do not seem to be very helpful.
> Lastly I should add that my impatience compounds the problem.
> I think my repeated control-g to wake up emacs while it id doing
> idle timer processing seems to make matters worse by making emacs
> even more sluggish.
Sorry for the slow response.
If emacs gets into a funk and you think it is related to the sematnic
idle timer, you can use:
to try out the two parts of the idle timer.
The only case where I have seen a situation similar to what you describe
is at my work, where the idle timer went off and parsed a gig or so of
"nearby" code and headers, causing Emacs' working set size to cause it
to continuously swap.
If it hangs up, you can check in ps or top to see if that is the issue.
In that case, the "hang" you see that you can't break out of is
probably the garbage collector, which runs just before semantic parser a
buffer, and you cannot break out of it, and if Emacs is swapping, will
take a very long time.
Faster to just check from your OS how big Emacs has gotten.
Quick fix - delete all your semanticdb files in that project, and then