Re: emacs 22.1 hogging CPU

Re: emacs 22.1 hogging CPU

[David L]

>I started emacs like this:
>emacs -l shared/sw/gvu/src/../bin/fc6debug1_1t/gtkview.nep2 -f 
>nep-build-and-load-tags -title >"fc6debug1_1t gtkview"
>
>For several minutes after I started it, emacs was using between 10%
>and 40% of a 3GHz P4.  This problem is either new with the 22.1
>release or is much worse now.  I don't know how to profile emacs
>to tell what's using the CPU, but emacs appears to be doing nothing
>at the time except waiting for user input... the building and loading
>of etags had long since finished.


emacs is now using 98.1% of a P4 3GHz while apparently doing
nothing.  It is continuously using more than 50%.
Here's the output of top:
26022 rmel  39  19  104m  37m  10m R 98.1  1.9  51:01.88 emacs

One of my co-workers is logged into my machine running emacs and
it is his session that is hogging the CPU.  I just went and talked to him
and he wasn't doing anything in that session.  He had left the emacs
code browser open, so I asked him to deactivate it to see if that would
make the problem go away.  It did not.  Is there a way to get emacs to
profile itself while this problem is happening so I can provide some
more useful debugging info?

Thanks,
           David

_________________________________________________________________
Hotmail to go? Get your Hotmail, news, sports and much more! 
http://mobile.msn.com

Re: emacs 22.1 hogging CPU

[Jason Rumney]

David L wrote:
> One of my co-workers is logged into my machine running emacs and
> it is his session that is hogging the CPU.

Is your co-worker using an old version of semantic?

Re: emacs 22.1 hogging CPU

[David L]

>David L wrote:
> > One of my co-workers is logged into my machine running emacs and
> > it is his session that is hogging the CPU.
>
>Is your co-worker using an old version of semantic?
>

semantic-version is a variable defined in `semantic.el'.
Its value is "2.0pre3"

It looks like there was a pre4 that came out a few days
after emacs 22.1.  I'll try having him upgrade to that.

Thanks,

David

_________________________________________________________________
Don’t miss your chance to WIN $10,000 and other great prizes from Microsoft 
Office Live http://clk.atdmt.com/MRT/go/aub0540003042mrt/direct/01/

Re: emacs 22.1 hogging CPU

[Richard Stallman]

    semantic-version is a variable defined in `semantic.el'.
    Its value is "2.0pre3"

    It looks like there was a pre4 that came out a few days
    after emacs 22.1.  I'll try having him upgrade to that.

I wonder if there is anything we can do to warn users about this.
For instance, in Emacs 22.2 we could add a feature would check
for version numbers (somehow) in files being loaded, and give an error
if they meet a criterion.

Maybe the feature could involve an alist whose elements look like
(FILE VARIABLE REGEXP ERROR).  It could be initialized to

(("semantic.el" semantic-version "2.0pre3"
  "Version %s of %s won't run in Emacs 22"))

Any comments or suggestions?

Re: emacs 22.1 hogging CPU

[Richard Stallman]

    semantic-version is a variable defined in `semantic.el'.
    Its value is "2.0pre3"

    It looks like there was a pre4 that came out a few days
    after emacs 22.1.  I'll try having him upgrade to that.

I wonder if there is anything we can do to warn users about this.
For instance, in Emacs 22.2 we could add a feature would check
for version numbers (somehow) in files being loaded, and give an error
if they meet a criterion.

Maybe the feature could involve an alist whose elements look like
(FILE VARIABLE REGEXP ERROR).  It could be initialized to

(("semantic.el" semantic-version "2.0pre3"
  "Version %s of %s won't run in Emacs 22"))

Any comments or suggestions?

Re: emacs 22.1 hogging CPU

[dhruva]

Hi,

On 7/23/07, Richard Stallman <rms@gnu.org> wrote:
> Maybe the feature could involve an alist whose elements look like
> (FILE VARIABLE REGEXP ERROR).  It could be initialized to
>
> (("semantic.el" semantic-version "2.0pre3"
>   "Version %s of %s won't run in Emacs 22"))

IMHO, since this data keeps changing (often or not), this should be
seperated from the general Emacs distribution. Also, this could be a
seperate package which can be loaded if the user wants. The error or
warning could be configured. At times, I may be evaluating a package
and would want to continue with a warning instead of an error which
prevents it from even getting loaded. The data file to drive such
checks could be hosted in the emacs wiki page (or some other place).
The distribution could carry the latest along with it.

Personally, I feel this will be very useful for users and also emacs
developer community in resolving issues. The data file can be a first
check to find out if it is a known issue.

-dky

-- 
Dhruva Krishnamurthy
Contents reflect my personal views only!

Re: emacs 22.1 hogging CPU

[Richard Stallman]

    > Maybe the feature could involve an alist whose elements look like
    > (FILE VARIABLE REGEXP ERROR).  It could be initialized to
    >
    > (("semantic.el" semantic-version "2.0pre3"
    >   "Version %s of %s won't run in Emacs 22"))

    IMHO, since this data keeps changing (often or not), this should be
    separated from the general Emacs distribution.

There must be a misunderstanding.  The idea of this feature is to warn
people about old versions of other programs that Emacs version M.N
won't work with.  (We can assume that new versions of those programs
will be fixed to work with the latest Emacs.)  So this list is fixed
for any given Emacs version.  The idea is to release it in Emacs.

Re: emacs 22.1 hogging CPU

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  >     semantic-version is a variable defined in `semantic.el'.
  >     Its value is "2.0pre3"
  > 
  >     It looks like there was a pre4 that came out a few days
  >     after emacs 22.1.  I'll try having him upgrade to that.
  > 
  > I wonder if there is anything we can do to warn users about this.
  > For instance, in Emacs 22.2 we could add a feature would check
  > for version numbers (somehow) in files being loaded, and give an error
  > if they meet a criterion.
  > 
  > Maybe the feature could involve an alist whose elements look like
  > (FILE VARIABLE REGEXP ERROR).  It could be initialized to
  > 
  > (("semantic.el" semantic-version "2.0pre3"
  >   "Version %s of %s won't run in Emacs 22"))
  > 
  > Any comments or suggestions?

We would have to support a feature like this until the end of time for
something that is not that likely to repeat. 
Has something like this happened in the past? Many times?
IMVHO it does not seem like a good idea.

Maybe we can get the semantic people to send an email to their mailing
list (if there is one) and put a note prominent note on the website
about this issue. 

Re: emacs 22.1 hogging CPU

[Stefan Monnier]

> We would have to support a feature like this until the end of time for
> something that is not that likely to repeat.
> Has something like this happened in the past?

Yes.

> Many times?

For Emacs-21, there was at least cua-mode (which broke if the user had an
older version of it in its load-path) plus a few more (calc comes to mind).

Every time we introduce incompatibility, we're bound to encounter such
things.  Incompatibilities are introduced at least at each major version.


        Stefan

Re: emacs 22.1 hogging CPU

[Richard Stallman]

    We would have to support a feature like this until the end of time for
    something that is not that likely to repeat. 

"Support" is ambiguous in this context.

If it means that we won't delete this feature, I agree, but that is
not a problem.  We just won't delete it.

If it means "continue to change and pay attention to", then I
disagree.  We won't ever have to change the list, except when we find
another case that we want to warn users about.  Then we can add that
case.  So this won't require attention except when it is advantageous
for us to pay attention.

Would someone please implement this, then ack?

solved: Re: emacs 22.1 hogging CPU

[David L]

>David L wrote:
> > One of my co-workers is logged into my machine running emacs and
> > it is his session that is hogging the CPU.
>
>Is your co-worker using an old version of semantic?

Although I don't have enough statistics to say for sure,
changing from cedet 1.0pre3 to pre4 seems to have
fixed the emacs CPU hogging problem.  Thanks for
the feedback.  If I see the problem again, I'll follow
up again after running gdb on emacs as RMS
suggested.

Thanks,

          David

PS - Sorry if this was not the appropriate mailing
list to report this problem.

_________________________________________________________________
Make every IM count. Download Messenger and join the i’m Initiative now. 
It’s free. http://im.live.com/messenger/im/home/?source=TAGHM_June07

emacs 22.1 hogging CPU

[David L]

I started emacs like this:
        emacs  -l shared/sw/gvu/src/../bin/fc6debug1_1t/gtkview.nep2 -f 
nep-build-and-load-tags -title "fc6debug1_1t gtkview"

For several minutes after I started it, emacs was using between 10%
and 40% of a 3GHz P4.  This problem is either new with the 22.1
release or is much worse now.  I don't know how to profile emacs
to tell what's using the CPU, but emacs appears to be doing nothing
at the time except waiting for user input... the building and loading
of etags had long since finished.


The contents of the gtkview.nep2 file looked like this:
(defconst nep-project-name "shared/sw/gvu/bin/fc6debug1_1t/gtkview.nep"
  "Define the full name of this project file relative to the CVS root 
level")
(defconst nep-build-dir "shared/sw/gvu/src"
  "Defines the build directory relative to the CVS root level")
(defconst nep-bin-dir "shared/sw/gvu/src/../bin"
  "Defines the bin directory relative to the CVS root level")
(defconst nep-exec-root "gtkview"
  "Defines the DL-style executable root name")
(defconst nep-build-script "./buildgtkview"
  "Defines the DL-style buildscript")
(defconst nep-build-target "fc6debug1_1t"
  "Defines the DL-style target")
(defun nep-debug-project ()
(interactive)
(gdb "gdb -cd=/projects/ct/team/dl/tim/svncvs/trunk/shared/sw/gvu/src 
--annotate=3 
/projects/ct/team/dl/tim/svncvs/trunk/shared/sw/gvu/src/../bin/fc6debug1_1t/gtkview"))
(defconst nep-tags-file-name  
"/projects/ct/team/dl/tim/svncvs/trunk/shared/sw/gvu/src/../bin/fc6debug1_1t/gtkview.etags")
  (defconst nep-cvsrootlevel "/projects/ct/team/dl/tim/svncvs/trunk")
  (defconst nep-current-project 
"/projects/ct/team/dl/tim/svncvs/trunk/shared/sw/gvu/src/../bin/fc6debug1_1t/gtkview.el")
  (defconst nep-current-project-makefile 
"shared/sw/gvu/src/makefile.gtkview")


The function nep-build-and-load-tags looks like this:
;; function called when using the "emacs" target
(defun nep-build-and-load-tags ()
  (add-hook 'compilation-finish-functions 'nep-load-tags-after-compile)
  (nep-build-etags)
  (visit-tags-table nep-tags-file-name)
  (find-tag "main")
)

The function nep-build-etags looks like this:
(defun nep-build-etags ()
  (interactive)
  (compile (concat "cd " nep-cvsrootlevel "/"
                   nep-build-dir "; "
                   nep-build-script " "
                   nep-build-target " etags"))
  )


The problem seems to be intermittent.


If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
/usr/local/share/emacs/22.1/etc/DEBUG for instructions.


In GNU Emacs 22.1.1 (i686-pc-linux-gnu, GTK+ Version 2.10.8)
of 2007-06-18 on chewbacca.x.com
Windowing system distributor `The X.Org Foundation', version 11.0.70101000
configured using `configure  '--with-x-toolkit=gtk''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: nil
  locale-coding-system: nil
  default-enable-multibyte-characters: t

Major mode: C++/l

Minor modes in effect:
  tooltip-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  line-number-mode: t
  abbrev-mode: t

Recent input:
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <menu-bar> <help-menu> <report-emacs-b
ug>

Recent messages:
Loading cc-mode...done
Loading /home/dl/ecb/semantic-1.4.4/semantic-c.el (source)...done
Loading vc-svn...done
Loading vc...done
Mark set
(iconify-frame (#<frame emacs@chewbacca.x.com 0x85f0e28>))
(make-frame-visible (#<frame emacs@chewbacca.x.com 0x85f0e28>))
(iconify-frame (#<frame emacs@chewbacca.x.com 0x85f0e28>))
(make-frame-visible (#<frame emacs@chewbacca.x.com 0x85f0e28>))
Loading emacsbug...done

_________________________________________________________________
Like puzzles? Play free games & earn great prizes. Play Clink now. 
http://club.live.com/clink.aspx?icid=clink_hotmailtextlink2