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: 1.5.24 hangs through ssh

Your good Dave.

$ echo "y
" | Z: /FS:NTFS /Q /V:zlbl
The type of the file system is RAW.
The new file system is NTFS.

Proceed with Format (Y/N)?
QuickFormatting 100m
Creating file system structures.
Format complete.
   102399 KB total disk space.
   100126 KB are available

Yay! Thank you.


Dave Korn wrote:
On 05 December 2007 18:18, srp wrote:

windbg stack after answering "Proceed with Format (Y/N)?" is
0:002> ~*
    0  Id: 5bc.ce0 Suspend: 1 Teb: 7ffdf000 Unfrozen
       Start: format!mainCRTStartup (010067ea)
       Priority: 0  Priority class: 32  Affinity: f
    1  Id: 5bc.fac Suspend: 1 Teb: 7ffde000 Unfrozen
       Start: kernel32!BaseThreadStartThunk (77e617ec)
       Priority: 0  Priority class: 32  Affinity: f
.  2  Id: 5bc.d34 Suspend: 1 Teb: 7ffdd000 Unfrozen
       Start: ntdll!DbgUiRemoteBreakin (7c83fdb4)
       Priority: 0  Priority class: 32  Affinity: f

Thread 2 is a special thread created by the debugger to get your process stopped and under debug control by issuing an exception from within the process context.

Thread 1 is the cygwin signal-handling thread.

Thread 0 is the actual main application itself.

0:001> ~0s
7c8285ec c3              ret
0:000> k
ChildEBP RetAddr
0006f748 7c82776b ntdll!KiFastSystemCallRet
0006f74c 77e418b2 ntdll!NtReadFile+0xc
0006f7b4 71f8b9ba kernel32!ReadFile+0x16c
0006f7dc 71f84ea8 ulib!PIPE_STREAM::FillBuffer+0x3c
0006f820 71f8523c ulib!BUFFER_STREAM::GetBuffer+0x30
0006f898 71f8c72c ulib!BUFFER_STREAM::ReadString+0x44
0006f8d4 71f8c857 ulib!STREAM_MESSAGE::ReadLine+0x5c
0006f934 01005b8c ulib!STREAM_MESSAGE::IsYesResponse+0x70
0006ff44 01006919 format!main+0x992
0006ffc0 77e6f23b format!mainCRTStartup+0x12f
0006fff0 00000000 kernel32!BaseProcessStart+0x23

I am unable to step into ~0 without hitting the hang.

I think all this means is that the thread is in a wait state, as in it has called WaitForMultipleObjects or similar. The thread is not really hung so much as it is in a not-ready-for-scheduling state, so the kernel is not giving it any cpu time.

I am able to trace into ~1 after waiting a bit for the initial step to
complete. ~1 seems to be spinning un-checked.  I see what seems to be a
regular repeated pattern of cmds here.

Process Explorer prior to "Proceed with Format (Y/N)?" PE shows the that
the thread stack is:<address>

After answering (Y/N)? ntdll.dll! goes away.

No new threads start and the format stack does not change.  The state
continues to be Wait:Executive and no user or kernel time accumulates.
Am I missing the thread seen in windbg or am I stuck in the kernel

You are seeing thread 0, the main thread, in the wait state. It might be instructive if you could find out what handle it is waiting for - looking at the presence of "IsYesResponse" in the stack trace, it seems as if despite your pressing Y or N, the key event has not been delivered to wake up the thread.


Unsubscribe info:
Problem reports:

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