This is the mail archive of the
cygwin@cygwin.com
mailing list for the Cygwin project.
Re: Cygwin Emacs-X uses 99% of cpu
- From: Igor Pechtchanski <pechtcha at cs dot nyu dot edu>
- To: "Huang." <hzhr at 21cn dot com>
- Cc: cygwin at cygwin dot com
- Date: Wed, 13 Nov 2002 10:14:08 -0500 (EST)
- Subject: Re: Cygwin Emacs-X uses 99% of cpu
- Reply-to: cygwin at cygwin dot com
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/