This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Cygwin Emacs-X uses 99% of cpu


On Wed, 13 Nov 2002, Huang. wrote:

> Igor Pechtchanski wrote:
>     > On Wed, 13 Nov 2002, Huang. wrote:
>     >
>     >
>     >>"J. Scott Edwards" <sedwards@xmission.com> wrote:
>     >>
>     >>>[snip]
>     >>
>     >>Oh! I have this problem too.
>     >
>     >
>     > For the archives:
>     > This is an example of a completely useless message.  It doesn't add
>     > anything at all to the discussion, and takes up list bandwidth.
> OK, you are right.

Sorry, didn't mean to sound that harsh, but I'm glad I could shock some
useful data out of people... :-)

>     >
>     > Attaching the output of cygcheck would have made it marginally useful
>     > (i.e., reporting that the problem can be reproduced on a particular
>     > configuration).  A good contribution would have been to run emacs under
>     > strace, for example, and provide the output (hopefully bzipped, preferably
>     > with repeated patterns removed, ideally with some analysis attached).
>     > Another would be to run emacs under gdb, break execution when in 100% cpu
>     > mode, and post the stack trace.
>     > 	Igor
>
> I tried your way.
>
> here is my cygcheck -s :
> Cygwin Win95/NT Configuration Diagnostics
> Current System Time: Wed Nov 13 12:46:13 2002
>
> Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 3
> [snip]

Thanks, but next time, please provide the output of "cygcheck -s -v -r" as
an *attachment*, as indicated in http://cygwin.com/bugs.html

> run emacs under gdb, can't break execution when in 100% cpu mode, didn't know
> why.

If emacs is looping on signal delivery, it's unlikely you can squeeze another
signal in...

> run emacs under strace, when in 100% cpu, just repeats the following :
> (repeat)
>     106 202207420 [sig] emacs 1692 wait_sig: looping
>     128 202207548 [sig] emacs 1692 wait_sig: awake
>     108 202207656 [sig] emacs 1692 wait_sig: processing signal 14
>     129 202207785 [sig] emacs 1692 wait_sig: Got signal 14
>     105 202207890 [sig] emacs 1692 sig_handle: signal 14
>     123 202208013 [sig] emacs 1692 sig_handle: signal 14, about to call 0x201240A4
>     108 202208121 [sig] emacs 1692 setup_handler: suspending mainthread
>     193 202208314 [sig] emacs 1692 interruptible: pc 0x77E7E8BB, h 0x77E60000, interruptible 1, testvalid 1
>     149 202208463 [sig] emacs 1692 interruptible: pc 0x77E7E8BB, h 0x77E60000, interruptible 0, testvalid 0
>     131 202208594 [sig] emacs 1692 setup_handler: couldn't send signal 14
>     117 202208711 [sig] emacs 1692 setup_handler: ResumeThread returned 1
>     125 202208836 [sig] emacs 1692 setup_handler: returning 0
>     106 202208942 [sig] emacs 1692 sig_handle: returning 0
> (repeat)
>
> i can't attach the file, it is larger than 12M in running 3 minutes.

You did even better than that, you've identified and attached the useful
part of the trace.  That's what I meant by "analysis".  I think this will
be very helpful in debugging this problem to someone who knows about
cygwin's signal delivery mechanism.

> Thanks.

Thanks to all who contributed!
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Water molecules expand as they grow warmer" (C) Popular Science, Oct'02, p.51


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]