CEDET

Hi,

  All the idle hooks in CEDET allow C-g to get through, so you can use
M-x toggle-debug-on-quit RET

  and then C-g should show a useful stack trace.

Alternately, if you find a place that has this slowdown, you can do put
a cursor there, and use:

M-x semantic-debug-idle-function RET

and/or

M-x semantic-debug-idle-work-function RET

to force those idle features to run with various debug flags turned on.

Once you get a stack with toggle-debug-on-quit in one of these
situations, if you read the stack, you will likely see the name of one
of the idle features there.  You can then turn it off to revive the
speed you would like.

Since you are using a particularly large code base, and it is plain C,
you can probably use GNU Global and the CEDET features it uses to get
good performance looking up symbols with minimal CEDET configuration.

It may also be you just need to let the idle process run to completion
sometime.  ie, just let it sit for a while, and when it is done, all the
symbols will be saved away for later use, and it may not do it again.

Eric

On Fri, 2009-06-19 at 13:49 +0300, Laurynas Biveinis wrote:
> Hello -
> 
> I've been experiencing a problem with CEDET. I am working with quite
> large C codebase. Ocasionally Emacs (I am using version 22.1) hangs
> for some time (in the middle of typing or idling) and wakes up after
> shorter or longer time interval. C-g beeps but does not recover.
> 
> However now I started experiencing that Emacs hangs in a few seconds
> after visiting any .c file (no matter if it is idle or not). First the
> screen becomes garbled, with pieces of code shuffled around randomly,
> then after a few keypresses Emacs becomes unresponsive and C-g drops
> me into shell (i am using emacs -nw). Right before it happens, the
> last thing I see on the mode line is "Loading semantic-complete...
> ok".
> 
> I have tried 1.0pre6 and CVS version as of today. Same results. I am
> not sure myself how to continue with finding the cause of this, any
> help would be appreciated.
> 
> Relevant part of my .emacs is -
> 
> (load-file cedet-lib)
> (global-ede-mode t)
> (semantic-load-enable-excessive-code-helpers)
> ; TODO: should already be enabled by previous line
> (global-semantic-idle-completions-mode)
> (global-semantic-tag-folding-mode)
> (require 'semantic-ia)
> (require 'semantic-gcc)
> 
> where cedet-lib is a variable with path to cedet.el. Also there are
> some key bindings for the cc-mode which hopefully are not relevant
> here.
> 
> Any ideas? Thanks in advance.

Hi,

Thanks for your suggestions. My replies are below.

>  All the idle hooks in CEDET allow C-g to get through, so you can use
> M-x toggle-debug-on-quit RET
>
>  and then C-g should show a useful stack trace.

Uhm, it doesn't. I do M-x toggle-debug-on-quit, then proceed to visit
a .c file, then after the buffer contents become thrashed, C-g still
drops me into shell. No stacktrace. It goes like this:

lauris@...:~$ emacs -nw

C-g here -----> [1]+  Stopped                 emacs -nw
lauris@...:~$ fg
emacs -nw
Auto-save? (y or n) y
Auto-save done
Abort (and dump core)? (y or n) y
Fatal error (6)^[OA^[OB^[OAAborted

If I choose not to abort, then I get "Continuing..." on console and
nothing else happens.

> Alternately, if you find a place that has this slowdown, you can do put
> a cursor there, and use:
>
> M-x semantic-debug-idle-function RET
>
> and/or
>
> M-x semantic-debug-idle-work-function RET
>
> to force those idle features to run with various debug flags turned on.

There is no local place in the file which has a slowdown. I can keep
the cursor inside the comment block, for example, with same results.

> Once you get a stack with toggle-debug-on-quit in one of these
> situations, if you read the stack, you will likely see the name of one
> of the idle features there.  You can then turn it off to revive the
> speed you would like.

I think it's not about speed, it's about not hanging/crashing emacs :)
I use the same CEDET version with same codebase under Emacs 22.2 (the
problems I describe here are on 22.1) and slowdown because of parsing
the source code is noticeable but nothing like this.

> Since you are using a particularly large code base, and it is plain C,
> you can probably use GNU Global and the CEDET features it uses to get
> good performance looking up symbols with minimal CEDET configuration.

Yes, I am planning to try GNU Global

> It may also be you just need to let the idle process run to completion
> sometime.  ie, just let it sit for a while, and when it is done, all the
> symbols will be saved away for later use, and it may not do it again.

Again, with Emacs 22.2 the idle process runs to completion quite fast.

So, all in all, I'm puzzled. I don't think that I am experiencing just
a slowdown due to parsing, but rather something bad in CEDET/Emacs
22.1 interaction, maybe some Emacs core bug, which was present in 22.1
but was fixed in 22.2?

Thanks again,
-- 
Laurynas

Why do you not use Emacs 22.2 or greater if there is no problem?
Why instisting in Ewmacs 22.1 - just use the current official release 22.3!

Klaus

-----Ursprüngliche Nachricht-----
Von: Laurynas Biveinis [mailto:laurynas.biveinis@...] 
Gesendet: Dienstag, 23. Juni 2009 16:32
An: eric@...
Cc: cedet-semantic@...
Betreff: Re: [cedet-semantic] CEDET hangs Emacs?

Hi,

Thanks for your suggestions. My replies are below.

>  All the idle hooks in CEDET allow C-g to get through, so you can use 
> M-x toggle-debug-on-quit RET
>
>  and then C-g should show a useful stack trace.

Uhm, it doesn't. I do M-x toggle-debug-on-quit, then proceed to visit a .c file, then after the buffer contents become thrashed, C-g still drops me into shell. No stacktrace. It goes like this:

lauris@...:~$ emacs -nw

C-g here -----> [1]+  Stopped                 emacs -nw
lauris@...:~$ fg
emacs -nw
Auto-save? (y or n) y
Auto-save done
Abort (and dump core)? (y or n) y
Fatal error (6)^[OA^[OB^[OAAborted

If I choose not to abort, then I get "Continuing..." on console and nothing else happens.

> Alternately, if you find a place that has this slowdown, you can do 
> put a cursor there, and use:
>
> M-x semantic-debug-idle-function RET
>
> and/or
>
> M-x semantic-debug-idle-work-function RET
>
> to force those idle features to run with various debug flags turned on.

There is no local place in the file which has a slowdown. I can keep the cursor inside the comment block, for example, with same results.

> Once you get a stack with toggle-debug-on-quit in one of these 
> situations, if you read the stack, you will likely see the name of one 
> of the idle features there.  You can then turn it off to revive the 
> speed you would like.

I think it's not about speed, it's about not hanging/crashing emacs :) I use the same CEDET version with same codebase under Emacs 22.2 (the problems I describe here are on 22.1) and slowdown because of parsing the source code is noticeable but nothing like this.

> Since you are using a particularly large code base, and it is plain C, 
> you can probably use GNU Global and the CEDET features it uses to get 
> good performance looking up symbols with minimal CEDET configuration.

Yes, I am planning to try GNU Global

> It may also be you just need to let the idle process run to completion 
> sometime.  ie, just let it sit for a while, and when it is done, all 
> the symbols will be saved away for later use, and it may not do it again.

Again, with Emacs 22.2 the idle process runs to completion quite fast.

So, all in all, I'm puzzled. I don't think that I am experiencing just a slowdown due to parsing, but rather something bad in CEDET/Emacs
22.1 interaction, maybe some Emacs core bug, which was present in 22.1 but was fixed in 22.2?

Thanks again,
--
Laurynas

------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
_______________________________________________
cedet-semantic mailing list
cedet-semantic@...
https://lists.sourceforge.net/lists/listinfo/cedet-semantic

Because I'm not 100% positive that this is indeed a bug in 22.1. This
Emacs version is packaged in Ubuntu 8.04 LTS, to upgrade I'd have to
build it myself, which I'd like to avoid if possible.

2009/6/23  <klaus.berndl@...>:
> Why do you not use Emacs 22.2 or greater if there is no problem?
> Why instisting in Ewmacs 22.1 - just use the current official release 22.3!
>
> Klaus
>
> -----Ursprüngliche Nachricht-----
> Von: Laurynas Biveinis [mailto:laurynas.biveinis@...]
> Gesendet: Dienstag, 23. Juni 2009 16:32
> An: eric@...
> Cc: cedet-semantic@...
> Betreff: Re: [cedet-semantic] CEDET hangs Emacs?
>
> Hi,
>
> Thanks for your suggestions. My replies are below.
>
>>  All the idle hooks in CEDET allow C-g to get through, so you can use
>> M-x toggle-debug-on-quit RET
>>
>>  and then C-g should show a useful stack trace.
>
> Uhm, it doesn't. I do M-x toggle-debug-on-quit, then proceed to visit a .c file, then after the buffer contents become thrashed, C-g still drops me into shell. No stacktrace. It goes like this:
>
> lauris@...:~$ emacs -nw
>
> C-g here -----> [1]+  Stopped                 emacs -nw
> lauris@...:~$ fg
> emacs -nw
> Auto-save? (y or n) y
> Auto-save done
> Abort (and dump core)? (y or n) y
> Fatal error (6)^[OA^[OB^[OAAborted
>
> If I choose not to abort, then I get "Continuing..." on console and nothing else happens.
>
>> Alternately, if you find a place that has this slowdown, you can do
>> put a cursor there, and use:
>>
>> M-x semantic-debug-idle-function RET
>>
>> and/or
>>
>> M-x semantic-debug-idle-work-function RET
>>
>> to force those idle features to run with various debug flags turned on.
>
> There is no local place in the file which has a slowdown. I can keep the cursor inside the comment block, for example, with same results.
>
>> Once you get a stack with toggle-debug-on-quit in one of these
>> situations, if you read the stack, you will likely see the name of one
>> of the idle features there.  You can then turn it off to revive the
>> speed you would like.
>
> I think it's not about speed, it's about not hanging/crashing emacs :) I use the same CEDET version with same codebase under Emacs 22.2 (the problems I describe here are on 22.1) and slowdown because of parsing the source code is noticeable but nothing like this.
>
>> Since you are using a particularly large code base, and it is plain C,
>> you can probably use GNU Global and the CEDET features it uses to get
>> good performance looking up symbols with minimal CEDET configuration.
>
> Yes, I am planning to try GNU Global
>
>> It may also be you just need to let the idle process run to completion
>> sometime.  ie, just let it sit for a while, and when it is done, all
>> the symbols will be saved away for later use, and it may not do it again.
>
> Again, with Emacs 22.2 the idle process runs to completion quite fast.
>
> So, all in all, I'm puzzled. I don't think that I am experiencing just a slowdown due to parsing, but rather something bad in CEDET/Emacs
> 22.1 interaction, maybe some Emacs core bug, which was present in 22.1 but was fixed in 22.2?
>
> Thanks again,
> --
> Laurynas
>
> ------------------------------------------------------------------------------
> Are you an open source citizen? Join us for the Open Source Bridge conference!
> Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
> Need another reason to go? 24-hour hacker lounge. Register today!
> http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
> _______________________________________________
> cedet-semantic mailing list
> cedet-semantic@...
> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>



-- 
Laurynas

AFAIK version XX.Y where Y is > 1 are molstly bug fix releases with only a few new features...all the new stuff is mostly in the .1 version so it's obviously that there can be guggs which have a good chance to be fixed in a .2, .3 or .4 version - so IMHO builing and using 22.3 instead of 22.1 is worth a try and probbaly also worth the effort....

I'm not a linux-guy but AFAIK builing an emacs is not rerally hard because Linux has all on board what is necessary - often calling ./configure & make is enough ;-)

Ciao,
Klaus 

-----Ursprüngliche Nachricht-----
Von: Laurynas Biveinis [mailto:laurynas.biveinis@...] 
Gesendet: Dienstag, 23. Juni 2009 17:09
An: Berndl, Klaus
Cc: eric@...; cedet-semantic@...
Betreff: Re: [cedet-semantic] CEDET hangs Emacs?

Because I'm not 100% positive that this is indeed a bug in 22.1. This Emacs version is packaged in Ubuntu 8.04 LTS, to upgrade I'd have to build it myself, which I'd like to avoid if possible.

2009/6/23  <klaus.berndl@...>:
> Why do you not use Emacs 22.2 or greater if there is no problem?
> Why instisting in Ewmacs 22.1 - just use the current official release 22.3!
>
> Klaus
>
> -----Ursprüngliche Nachricht-----
> Von: Laurynas Biveinis [mailto:laurynas.biveinis@...]
> Gesendet: Dienstag, 23. Juni 2009 16:32
> An: eric@...
> Cc: cedet-semantic@...
> Betreff: Re: [cedet-semantic] CEDET hangs Emacs?
>
> Hi,
>
> Thanks for your suggestions. My replies are below.
>
>>  All the idle hooks in CEDET allow C-g to get through, so you can use 
>> M-x toggle-debug-on-quit RET
>>
>>  and then C-g should show a useful stack trace.
>
> Uhm, it doesn't. I do M-x toggle-debug-on-quit, then proceed to visit a .c file, then after the buffer contents become thrashed, C-g still drops me into shell. No stacktrace. It goes like this:
>
> lauris@...:~$ emacs -nw
>
> C-g here -----> [1]+  Stopped                 emacs -nw lauris@...:~$ 
> fg emacs -nw Auto-save? (y or n) y Auto-save done Abort (and dump 
> core)? (y or n) y Fatal error (6)^[OA^[OB^[OAAborted
>
> If I choose not to abort, then I get "Continuing..." on console and nothing else happens.
>
>> Alternately, if you find a place that has this slowdown, you can do 
>> put a cursor there, and use:
>>
>> M-x semantic-debug-idle-function RET
>>
>> and/or
>>
>> M-x semantic-debug-idle-work-function RET
>>
>> to force those idle features to run with various debug flags turned on.
>
> There is no local place in the file which has a slowdown. I can keep the cursor inside the comment block, for example, with same results.
>
>> Once you get a stack with toggle-debug-on-quit in one of these 
>> situations, if you read the stack, you will likely see the name of 
>> one of the idle features there.  You can then turn it off to revive 
>> the speed you would like.
>
> I think it's not about speed, it's about not hanging/crashing emacs :) I use the same CEDET version with same codebase under Emacs 22.2 (the problems I describe here are on 22.1) and slowdown because of parsing the source code is noticeable but nothing like this.
>
>> Since you are using a particularly large code base, and it is plain 
>> C, you can probably use GNU Global and the CEDET features it uses to 
>> get good performance looking up symbols with minimal CEDET configuration.
>
> Yes, I am planning to try GNU Global
>
>> It may also be you just need to let the idle process run to 
>> completion sometime.  ie, just let it sit for a while, and when it is 
>> done, all the symbols will be saved away for later use, and it may not do it again.
>
> Again, with Emacs 22.2 the idle process runs to completion quite fast.
>
> So, all in all, I'm puzzled. I don't think that I am experiencing just 
> a slowdown due to parsing, but rather something bad in CEDET/Emacs
> 22.1 interaction, maybe some Emacs core bug, which was present in 22.1 but was fixed in 22.2?
>
> Thanks again,
> --
> Laurynas
>
> ----------------------------------------------------------------------
> -------- Are you an open source citizen? Join us for the Open Source 
> Bridge conference!
> Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
> Need another reason to go? 24-hour hacker lounge. Register today!
> http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebr
> idge.org _______________________________________________
> cedet-semantic mailing list
> cedet-semantic@...
> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>



--
Laurynas