This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: How to debug mintty or screen freeze


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]