On 15 November 2010 10:25, Henry S. Thompson wrote: > Andy Koppe writes: > >> On 8 November 2010 10:15, Henry S. Thompson wrote: >>> Bear with me please, this is moderately complex: >>> >>> . . .the whole thing freezes solid. >>> >>> screen doesn't respond to escape commands, ~. does nothing, Control-C >>> has no effect, trying to close the window results in the "process not >>> responding" popup. >>> >>> It's not repeatable, in that reconnecting and changing to the same >>> gnus Subject buffer will succeed. >>> >>> I _presume_ some obscure character code is responsible. . . >>> >>> Two questions: >>> >>> 1) Anyone else seen anything like this? >> >> Not as such, but it could be to do with the following issue: if you >> cat a big file and press any key that sends a character, the terminal >> and cat will be deadlocked, like so: >> >> $ ps >> O 2408 1 2408 2408 ? 99498 12:27:13 /usr/bin/mintty >> O 2672 2772 2672 1580 5 99498 12:27:19 /usr/bin/cat >> >> They're both in write(), waiting for each other to read data from >> their side of the pty. Happens with all the pty-based terminals. >> Killing the cat resolves the deadlock, and the terminal merrily >> continues. > > OK, that's not it -- the ps output is > > 5712 1 5712 5712 ? 1003 16:09:26 /c/Cygwin/bin/mintty > 5748 5712 5748 5768 1 1003 16:09:26 /usr/bin/screen > 6036 5748 6036 6036 ? 1003 16:09:27 /usr/bin/screen > > and procexp shows mintty at 50% of the CPU, i.e. 100% of one of them.
Shame. How come the mintty executable is shown as /c/Cygwin/bin/mintty rather than /usr/bin/mintty? Be careful in case there are multiple Cygwin DLLs involved. > Attaching with gdb shows > > #0 0x7c90120f in ntdll!DbgUiConnectToDbg () from > /c/WINDOWS/system32/ntdll.dll > #1 0x7c951e40 in ntdll!KiIntSystemCall () from > /c/WINDOWS/system32/ntdll.dll > #2 0x00000005 in ?? () > #3 0x00000004 in ?? () > #4 0x00000001 in ?? () > #5 0x19c3ffd0 in ?? () > #6 0xba338548 in ?? () > #7 0xffffffff in ?? () > #8 0x7c90e920 in strchr () from /c/WINDOWS/system32/ntdll.dll > #9 0x7c951e60 in ntdll!KiIntSystemCall () from > /c/WINDOWS/system32/ntdll.dll > #10 0x00000000 in ?? () > > in thread 6 and > > #0 0x6110b348 in memcpy () from /c/Cygwin/bin/cygwin1.dll > #1 0x610f393a in dlrealloc () from /c/Cygwin/bin/cygwin1.dll > #2 0x58ca0008 in ?? () > #3 0x698f0008 in ?? () > #4 0x082fffe8 in ?? () > #5 0x00000002 in ?? () > #6 0x0023c5bc in ?? () > #7 0x0000fffd in ?? () > #8 0x698f0008 in ?? () > #9 0x00506528 in ?? () > #10 0x08300000 in ?? () > #11 0x698f0008 in ?? () > #12 0x0023c8d0 in ?? () > #13 0x61071218 in realloc () from /c/Cygwin/bin/cygwin1.dll > #14 0x0000fffd in ?? () > #15 0x005062a0 in ?? () > #16 0x0000000e in ?? () > #17 0x00000009 in ?? () > #18 0x0000000f in ?? () > #19 0x005062a8 in ?? () > #20 0x0023c8d0 in ?? () > #21 0x00020500 in ?? () > #22 0x00506528 in ?? () > #23 0x0000000f in ?? () > #24 0x005062a8 in ?? () > #25 0x610c01a5 in _sigfe () from /c/Cygwin/bin/cygwin1.dll > #26 0x7475f1a6 in TF_InvalidAssemblyListCache () from > /c/WINDOWS/system32/MSCTF.dll > Cannot access memory at address 0x82fffec > > in thread 1 > > I expect those are no use. Not to me anyway, I'm afraid, but thanks for having a go. I assume you're using mintty-0.9.2 installed through setup.exe? Perhaps someone else has a better idea what do with the stackdumps then run them through 'addr2line -e mintty.exe', with mintty.exe built from the 0.9.2 sources with added -g and removed -s? > Should I try building a with-symbols version from source? Yes, please that give that a go. You can enable a debug build by putting 'debug=1' onto the make line. That will require the dmalloc library though. I'm afraid doing a release build with added debug symbols requires hacking the makefile: --- Makefile (revision 1077) +++ Makefile (working copy) @@ -32,8 +32,8 @@ cc_opts += -DDMALLOC -g ld_opts += -ldmallocth else -cc_opts += -DNDEBUG -fomit-frame-pointer -Os -ld_opts += -s +cc_opts += -DNDEBUG -fomit-frame-pointer -Os -g +ld_opts += endif Another thing you could try is to enable logging to a file using the --log command option. Perhaps that will show what control sequence triggers the problem. Obviously you'll want to remove any private details before sending the log. Andy -- 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
