How to debug mintty or screen freeze

[Andy Koppe]

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