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] |
Hi, I'm having trouble with the latest changes to the pty control code. In my case they manifest when I run parallel "make -j check" on GCC; after a minute or two all the expect processes end up spinning CPU and everything grinds to a halt. When I attach to and debug one of the stuck expect processes, I see 35 threads: - main thread stuck in a TransactNamedPipe call that never completes: > Thread 1 (thread 608.0xd38): > #0 0x77f884ff in ntdll!ZwFsControlFile () > from /win/c/WINNT/system32/ntdll.dll > #1 0x7c592692 in TransactNamedPipe () from /win/c/WINNT/system32/KERNEL32.dll > #2 0x7c5927f0 in KERNEL32!CallNamedPipeW () > from /win/c/WINNT/system32/KERNEL32.dll > #3 0x7c592754 in KERNEL32!CallNamedPipeA () > from /win/c/WINNT/system32/KERNEL32.dll > #4 0x61061564 in fhandler_pty_master::close (this=0x1) > at /gnu/winsup/src/winsup/cygwin/fhandler_tty.cc:1432 > #5 0x610dda7a in close (fd=6) > at /gnu/winsup/src/winsup/cygwin/syscalls.cc:1140 > #6 0x610c3a3a in _sigfe () from /usr/bin/cygwin1.dll - signal thread happily waiting for a signal: > Thread 2 (thread 608.0xbe0): > #0 0x77f88a87 in ntdll!ZwReadFile () from /win/c/WINNT/system32/ntdll.dll > #1 0x7c586381 in ReadFile () from /win/c/WINNT/system32/KERNEL32.dll > #2 0x610ca395 in wait_sig () at /gnu/winsup/src/winsup/cygwin/sigproc.cc:1194 - 32 threads all stuck in WFSO with no useful backtrace, and one that is frantically looping in cygthread::callfunc() at this point: > if (issimplestub) > { > /* Wait for main thread to assign 'h' */ > while (!h) > yield (); ... with "h" never getting set. The attached testcase demonstrates the underlying problem. It appears that a fresh cygthread is getting created to run the pty_master_thread function every time we open a new pty master, and for some reason they're never getting recycled. Then when the cygthread array fills up and we fall back to the simplestub mechanism, things go really wrong, and the main thread hangs up in a call to fhandler_pty_master::close that never completes while the latest spawned cygthread frantically loops waiting for something that will never happen. Compile with "gcc-4 t1.c -o t1", possibly adding "-DFAST" (or "-DRAPID") if you want to get it to the stuck state quickly. After 31 times round the loop, everything locks up, wheels spinning. And it can't be Ctrl-C'd at that point any more, nor even "kill -9"ed. Killing it in windows task manager, or attaching gdb to it and using gdb's kill command both work, and Ctrl-C works if you started it under gdb, just not when you start it from bash. Anyone got any ideas where I should be looking next? cheers, DaveK
Attachment:
t1.c
Description: Text document
-- 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] |