On Wed, 13 Nov 2002, Huang. wrote: > Igor Pechtchanski wrote: > > On Wed, 13 Nov 2002, Huang. wrote: > > > > > >>"J. Scott Edwards" <[EMAIL PROTECTED]> 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/ |\ _,,,---,,_ [EMAIL PROTECTED] ZZZzz /,`.-'`' -. ;-;;,_ [EMAIL PROTECTED] |,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/
