Re: emacs-nox hogs CPU if backgrounded during compile
On 27/08/2013 8:06 AM, Ken Brown wrote: On 8/27/2013 4:28 AM, Ryan Johnson wrote: On 17/08/2013 2:41 PM, Ryan Johnson wrote: Hi all, The following STC causes emacs-nox to peg a CPU indefinitely. Emacs remains responsive, but C-c C-k doesn't kill the compile; you have to exit emacs to remove the "Compiling" status. Killing the buffer or starting a new compile offers to kill the offending process, but doesn't. Attaching gdb shows an endless loop inside kernelbase.dll!RaiseException, but provides no other clues that I could see. 1. emacs-nox -Q 2. M-x compile 3. C-a C-k sleep 1; echo hi 4. ^Z (before the sleep finishes) 5. fg (after the sleep finishes) I don't know if this is related to limited pipe buffering, but I don't think so: it has always worked in the past, and the the 3-4 bytes required to buffer up "hi\n" is hardly onerous. $ uname -a CYGWIN_NT-6.1 ryan-laptop-v02 1.7.24(0.269/5/3) 2013-08-15 11:59 x86_64 Cygwin $ cygcheck -cd bash 4.1.11-1 cygwin1.7.24-1 emacs 24.3-5 mintty1.2-beta1-1 > Ping... is anyone else at least able to reproduce this? I can reproduce this on both x86 and x86_64, even without the "echo hi". Update: the problem only occurs if output arrives while emacs is stopped. So, "echo hi; sleep 5; echo ho" will not cause the problem if you ^Z/fg during the gap. Ryan -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: emacs-nox hogs CPU if backgrounded during compile
On 27/08/2013 8:06 AM, Ken Brown wrote: On 8/27/2013 4:28 AM, Ryan Johnson wrote: On 17/08/2013 2:41 PM, Ryan Johnson wrote: Hi all, The following STC causes emacs-nox to peg a CPU indefinitely. Emacs remains responsive, but C-c C-k doesn't kill the compile; you have to exit emacs to remove the "Compiling" status. Killing the buffer or starting a new compile offers to kill the offending process, but doesn't. Attaching gdb shows an endless loop inside kernelbase.dll!RaiseException, but provides no other clues that I could see. 1. emacs-nox -Q 2. M-x compile 3. C-a C-k sleep 1; echo hi 4. ^Z (before the sleep finishes) 5. fg (after the sleep finishes) I don't know if this is related to limited pipe buffering, but I don't think so: it has always worked in the past, and the the 3-4 bytes required to buffer up "hi\n" is hardly onerous. $ uname -a CYGWIN_NT-6.1 ryan-laptop-v02 1.7.24(0.269/5/3) 2013-08-15 11:59 x86_64 Cygwin $ cygcheck -cd bash 4.1.11-1 cygwin1.7.24-1 emacs 24.3-5 mintty1.2-beta1-1 > Ping... is anyone else at least able to reproduce this? I can reproduce this on both x86 and x86_64, even without the "echo hi". Since gdb doesn't seem to be helping, have you tried strace? I've attached a snippet of strace output; it is replicated endlessly in the log file I took, with increasing timestamps being the only difference AFAICT. The snippet itself in turn consists of a segment that is repeated three times, where the only meaningful difference is the value of "set_bits: me" And when you say this has always worked in the past, are you talking about earlier versions of emacs or earlier versions of cygwin? I migrated to 64-bit cygwin and emacs-24 at the same time (from 32-bit emacs-23), when my old computer's HDD died, so I don't have an easy way to answer that question. I didn't notice the problem at first, either, so I don't know if a subsequent update changed things (I doubt it, though, because I do remember a few times where emacs was hogging CPU and I didn't quite know what had happened, before I figured out what was going on). HTH, Ryan 27 6594315 [pipesel] emacs 7036 fhandler_pty_master::hit_eof: all other handles closed 17 6594332 [pipesel] emacs 7036 peek_pipe: read: /dev/ptmx, saw EOF 20 6594352 [main] emacs 7036 select_stuff::wait: wait_ret 2. verifying 16 6594368 [main] emacs 7036 set_bits: me 0x600029280, testing fd 4 (/dev/ptmx) 16 6594384 [main] emacs 7036 set_bits: ready 1 15 6594399 [main] emacs 7036 select_stuff::wait: gotone 1 15 6594414 [main] emacs 7036 select_stuff::wait: returning 0 16 6594430 [main] emacs 7036 select: res 0 15 6594445 [main] emacs 7036 peek_pipe: /dev/ptmx, already ready for read 15 6594460 [main] emacs 7036 set_bits: me 0x600029280, testing fd 4 (/dev/ptmx) 15 6594475 [main] emacs 7036 set_bits: ready 1 30 6594505 [main] emacs 7036 select_stuff::cleanup: calling cleanup routines 93 6594598 [main] emacs 7036 select_stuff::destroy: deleting select records 139 6594737 [main] emacs 7036 select_stuff::cleanup: calling cleanup routines 16 6594753 [main] emacs 7036 select_stuff::destroy: deleting select records 15 6594768 [main] emacs 7036 cygwin_select: 1 = select(5, 0x429B90, 0x429BA0, 0x0, 0x429920) 118 6594886 [main] emacs 7036 fcntl64: fcntl(3, 4, ...) 15 6594901 [main] emacs 7036 fhandler_base::set_flags: flags 0x1C002, supplied_bin 0x0 16 6594917 [main] emacs 7036 fhandler_base::set_flags: O_TEXT/O_BINARY set in flags 0x1 15 6594932 [main] emacs 7036 fhandler_base::set_flags: filemode set to binary 15 6594947 [main] emacs 7036 fcntl64: 0 = fcntl(3, 4, 0x4000) 117 6595064 [main] emacs 7036 read: read(3, 0x428900, 4095) nonblocking 15 6595079 [main] emacs 7036 fhandler_pty_slave::read: read(0x428900, 4095) handle 0x1B4 19 6595098 [main] emacs 7036 fhandler_pty_slave::read: wait timed out, time_to_wait 0 15 6595113 [main] emacs 7036 fhandler_pty_slave::read: -1=read(0x428900, 4095) 15 6595128 [main] emacs 7036 read: -1 = read(3, 0x428900, 4095), errno 11 117 6595245 [main] emacs 7036 fcntl64: fcntl(3, 4, ...) 15 6595260 [main] emacs 7036 fhandler_base::set_flags: flags 0x18002, supplied_bin 0x0 15 6595275 [main] emacs 7036 fhandler_base::set_flags: O_TEXT/O_BINARY set in flags 0x1 16 6595291 [main] emacs 7036 fhandler_base::set_flags: filemode set to binary 15 6595306 [main] emacs 7036 fcntl64: 0 = fcntl(3, 4, 0x0) 17 6595323 [main] emacs 7036 read: read(4, 0x4289E0, 4096) nonblocking 22 6595345 [main] emacs 7036 fhandler_pty_master::hit_eof: all other handles closed 15 6595360 [main] emacs 7036 fhandler_pty_master::process_slave_output: returning 0 15 6595375 [main] emacs 7036 read: 0 = read(4, 0x4289E0, 4096) 119 6595494 [main] emacs 7036 fcntl64: fcntl(3, 4, ...) 15 6595509 [main] emacs 7036 fhandler_base::set_flags: flags 0x1C
Re: emacs-nox hogs CPU if backgrounded during compile
On 8/27/2013 4:28 AM, Ryan Johnson wrote: On 17/08/2013 2:41 PM, Ryan Johnson wrote: Hi all, The following STC causes emacs-nox to peg a CPU indefinitely. Emacs remains responsive, but C-c C-k doesn't kill the compile; you have to exit emacs to remove the "Compiling" status. Killing the buffer or starting a new compile offers to kill the offending process, but doesn't. Attaching gdb shows an endless loop inside kernelbase.dll!RaiseException, but provides no other clues that I could see. 1. emacs-nox -Q 2. M-x compile 3. C-a C-k sleep 1; echo hi 4. ^Z (before the sleep finishes) 5. fg (after the sleep finishes) I don't know if this is related to limited pipe buffering, but I don't think so: it has always worked in the past, and the the 3-4 bytes required to buffer up "hi\n" is hardly onerous. $ uname -a CYGWIN_NT-6.1 ryan-laptop-v02 1.7.24(0.269/5/3) 2013-08-15 11:59 x86_64 Cygwin $ cygcheck -cd bash 4.1.11-1 cygwin1.7.24-1 emacs 24.3-5 mintty1.2-beta1-1 > Ping... is anyone else at least able to reproduce this? I can reproduce this on both x86 and x86_64, even without the "echo hi". Since gdb doesn't seem to be helping, have you tried strace? And when you say this has always worked in the past, are you talking about earlier versions of emacs or earlier versions of cygwin? In either case, you could try a bisection to see when the problem first appeared. I don't have time to try this myself right now. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: emacs-nox hogs CPU if backgrounded during compile
Ping... is anyone else at least able to reproduce this? On 17/08/2013 2:41 PM, Ryan Johnson wrote: Hi all, The following STC causes emacs-nox to peg a CPU indefinitely. Emacs remains responsive, but C-c C-k doesn't kill the compile; you have to exit emacs to remove the "Compiling" status. Killing the buffer or starting a new compile offers to kill the offending process, but doesn't. Attaching gdb shows an endless loop inside kernelbase.dll!RaiseException, but provides no other clues that I could see. 1. emacs-nox -Q 2. M-x compile 3. C-a C-k sleep 1; echo hi 4. ^Z (before the sleep finishes) 5. fg (after the sleep finishes) I don't know if this is related to limited pipe buffering, but I don't think so: it has always worked in the past, and the the 3-4 bytes required to buffer up "hi\n" is hardly onerous. $ uname -a CYGWIN_NT-6.1 ryan-laptop-v02 1.7.24(0.269/5/3) 2013-08-15 11:59 x86_64 Cygwin $ cygcheck -cd bash 4.1.11-1 cygwin1.7.24-1 emacs 24.3-5 mintty1.2-beta1-1 Ryan -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: emacs-nox hogs CPU if backgrounded during compile
On 18/08/2013 12:53 AM, Christopher Faylor wrote: On Sat, Aug 17, 2013 at 02:41:32PM -0400, Ryan Johnson wrote: The following STC causes emacs-nox to peg a CPU indefinitely. Emacs remains responsive, but C-c C-k doesn't kill the compile; you have to exit emacs to remove the "Compiling" status. Killing the buffer or starting a new compile offers to kill the offending process, but doesn't. Attaching gdb shows an endless loop inside kernelbase.dll!RaiseException, but provides no other clues that I could see. I don't know if this trick works on 64-bit Cygwin or not but you could try: set $rsp=$rbp bt And, if you get something sensible try it on every thread. (gdb) p $rbp $5 = (void *) 0x16 Ryan -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: emacs-nox hogs CPU if backgrounded during compile
On Sat, Aug 17, 2013 at 02:41:32PM -0400, Ryan Johnson wrote: >The following STC causes emacs-nox to peg a CPU indefinitely. Emacs >remains responsive, but C-c C-k doesn't kill the compile; you have to >exit emacs to remove the "Compiling" status. Killing the buffer or >starting a new compile offers to kill the offending process, but doesn't. > >Attaching gdb shows an endless loop inside >kernelbase.dll!RaiseException, but provides no other clues that I could see. I don't know if this trick works on 64-bit Cygwin or not but you could try: set $rsp=$rbp bt And, if you get something sensible try it on every thread. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
emacs-nox hogs CPU if backgrounded during compile
Hi all, The following STC causes emacs-nox to peg a CPU indefinitely. Emacs remains responsive, but C-c C-k doesn't kill the compile; you have to exit emacs to remove the "Compiling" status. Killing the buffer or starting a new compile offers to kill the offending process, but doesn't. Attaching gdb shows an endless loop inside kernelbase.dll!RaiseException, but provides no other clues that I could see. 1. emacs-nox -Q 2. M-x compile 3. C-a C-k sleep 1; echo hi 4. ^Z (before the sleep finishes) 5. fg (after the sleep finishes) I don't know if this is related to limited pipe buffering, but I don't think so: it has always worked in the past, and the the 3-4 bytes required to buffer up "hi\n" is hardly onerous. $ uname -a CYGWIN_NT-6.1 ryan-laptop-v02 1.7.24(0.269/5/3) 2013-08-15 11:59 x86_64 Cygwin $ cygcheck -cd bash 4.1.11-1 cygwin1.7.24-1 emacs 24.3-5 mintty1.2-beta1-1 Ryan -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
