X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-0.3 required=5.0 tests=AWL,BAYES_50,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,TW_CP,TW_XF,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: sourceware.org MIME-Version: 1.0 In-Reply-To: References:

Date: Mon, 15 Nov 2010 16:01:32 +0000 Message-ID: Subject: Re: How to debug mintty or screen freeze From: Andy Koppe To: cygwin AT cygwin DOT com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com 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: >>> >>> =C2=A01) 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 =C2=A0 =C2=A02408 =C2=A0 =C2=A0 =C2=A0 1 =C2=A0 =C2=A02408 =C2=A0 =C2= =A0 =C2=A0 2408 =C2=A0 =C2=A0? 99498 12:27:13 /usr/bin/mintty >> O =C2=A0 =C2=A02672 =C2=A0 =C2=A02772 =C2=A0 =C2=A02672 =C2=A0 =C2=A0 = =C2=A0 1580 =C2=A0 =C2=A05 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 > > =C2=A0 =C2=A0 5712 =C2=A0 =C2=A0 =C2=A0 1 =C2=A0 =C2=A05712 =C2=A0 =C2=A0= =C2=A0 5712 =C2=A0 =C2=A0? 1003 16:09:26 /c/Cygwin/bin/mintty > =C2=A0 =C2=A0 5748 =C2=A0 =C2=A05712 =C2=A0 =C2=A05748 =C2=A0 =C2=A0 =C2= =A0 5768 =C2=A0 =C2=A01 1003 16:09:26 /usr/bin/screen > =C2=A0 =C2=A0 6036 =C2=A0 =C2=A05748 =C2=A0 =C2=A06036 =C2=A0 =C2=A0 =C2= =A0 6036 =C2=A0 =C2=A0? 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 > > =C2=A0#0 =C2=A00x7c90120f in ntdll!DbgUiConnectToDbg () from =C2=A0/c/WIN= DOWS/system32/ntdll.dll > =C2=A0#1 =C2=A00x7c951e40 in ntdll!KiIntSystemCall () from =C2=A0/c/WINDO= WS/system32/ntdll.dll > =C2=A0#2 =C2=A00x00000005 in ?? () > =C2=A0#3 =C2=A00x00000004 in ?? () > =C2=A0#4 =C2=A00x00000001 in ?? () > =C2=A0#5 =C2=A00x19c3ffd0 in ?? () > =C2=A0#6 =C2=A00xba338548 in ?? () > =C2=A0#7 =C2=A00xffffffff in ?? () > =C2=A0#8 =C2=A00x7c90e920 in strchr () from /c/WINDOWS/system32/ntdll.dll > =C2=A0#9 =C2=A00x7c951e60 in ntdll!KiIntSystemCall () from =C2=A0/c/WINDO= WS/system32/ntdll.dll > =C2=A0#10 0x00000000 in ?? () > > in thread 6 and > > =C2=A0#0 =C2=A00x6110b348 in memcpy () from /c/Cygwin/bin/cygwin1.dll > =C2=A0#1 =C2=A00x610f393a in dlrealloc () from /c/Cygwin/bin/cygwin1.dll > =C2=A0#2 =C2=A00x58ca0008 in ?? () > =C2=A0#3 =C2=A00x698f0008 in ?? () > =C2=A0#4 =C2=A00x082fffe8 in ?? () > =C2=A0#5 =C2=A00x00000002 in ?? () > =C2=A0#6 =C2=A00x0023c5bc in ?? () > =C2=A0#7 =C2=A00x0000fffd in ?? () > =C2=A0#8 =C2=A00x698f0008 in ?? () > =C2=A0#9 =C2=A00x00506528 in ?? () > =C2=A0#10 0x08300000 in ?? () > =C2=A0#11 0x698f0008 in ?? () > =C2=A0#12 0x0023c8d0 in ?? () > =C2=A0#13 0x61071218 in realloc () from /c/Cygwin/bin/cygwin1.dll > =C2=A0#14 0x0000fffd in ?? () > =C2=A0#15 0x005062a0 in ?? () > =C2=A0#16 0x0000000e in ?? () > =C2=A0#17 0x00000009 in ?? () > =C2=A0#18 0x0000000f in ?? () > =C2=A0#19 0x005062a8 in ?? () > =C2=A0#20 0x0023c8d0 in ?? () > =C2=A0#21 0x00020500 in ?? () > =C2=A0#22 0x00506528 in ?? () > =C2=A0#23 0x0000000f in ?? () > =C2=A0#24 0x005062a8 in ?? () > =C2=A0#25 0x610c01a5 in _sigfe () from /c/Cygwin/bin/cygwin1.dll > =C2=A0#26 0x7475f1a6 in TF_InvalidAssemblyListCache () from /c/WINDOWS/sy= stem32/MSCTF.dll > =C2=A0Cannot 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=3D1' 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 +=3D -DDMALLOC -g ld_opts +=3D -ldmallocth else -cc_opts +=3D -DNDEBUG -fomit-frame-pointer -Os -ld_opts +=3D -s +cc_opts +=3D -DNDEBUG -fomit-frame-pointer -Os -g +ld_opts +=3D 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