X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-0.0 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,SPF_NEUTRAL,TW_TX,TW_XF,T_RP_MATCHES_RCVD,URIBL_BLACK X-Spam-Check-By: sourceware.org Message-ID: <4FCB5E7C.2000308@cornell.edu> Date: Sun, 03 Jun 2012 08:54:20 -0400 From: Ken Brown User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: "emacs -nw" hangs in a terminal References: <20120523141538 DOT GI9200 AT calimero DOT vinschen DOT de> <4FBD08B0 DOT 50209 AT cornell DOT edu> <20120523160235 DOT GK9200 AT calimero DOT vinschen DOT de> <4FBE26C8 DOT 1000008 AT cornell DOT edu> <20120525100321 DOT GF4225 AT calimero DOT vinschen DOT de> <4FBF7EDC DOT 2060502 AT cornell DOT edu> <20120525130314 DOT GJ4225 AT calimero DOT vinschen DOT de> <20120525143503 DOT GK4225 AT calimero DOT vinschen DOT de> <4FBFD447 DOT 3000909 AT cornell DOT edu> <4FBFE684 DOT 10106 AT cornell DOT edu> <20120603030832 DOT GA27486 AT ednor DOT casa DOT cgf DOT cx> In-Reply-To: <20120603030832.GA27486@ednor.casa.cgf.cx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-CORNELL-SPAM-CHECKED: Pawpaw X-Original-Sender: kbrown AT cornell DOT edu - Sun Jun 3 08:54:51 2012 X-PMX-CORNELL-REASON: CU_White_List_Override X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: 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 6/2/2012 11:08 PM, Christopher Faylor wrote: > On Fri, May 25, 2012 at 04:07:32PM -0400, Ken Brown wrote: >> On 5/25/2012 2:49 PM, Ken Brown wrote: >>> On 5/25/2012 10:35 AM, Corinna Vinschen wrote: >>>> I applied a patch which calls the signal handler after cleanup. The >>>> downside is that the signal handler is only called if select is called >>>> from the main thread. A better patch would perhaps be to stop all >>>> threads, call the signal handler, and restart the threads afterwards, >>>> but this is more tricky. >>> >>> Thanks! That fixes it. I appreciate all your work on this. >>> >>> I'm in the process now of testing to see if this also fixes an emacs >>> crash I've been getting when I build emacs with GSettings support >>> (http://cygwin.com/ml/cygwin-xfree/2012-04/msg00048.html). >> >> Here's what I'm now seeing with that build. If I start emacs and do >> 'M-x shell', emacs hangs (but doesn't crash). Attaching gdb and doing a >> backtrace of all threads, I see that cygwin_select has been called in >> two threads other than the main one: >> >> Thread 8 (Thread 2784.0x19c): >> #0 0x7702013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation () >> from /c/windows/SysWOW64/ntdll.dll >> #1 0x7702013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation () >> from /c/windows/SysWOW64/ntdll.dll >> #2 0x74fe0bdd in WaitForMultipleObjectsEx () >> from /c/windows/syswow64/KERNELBASE.dll >> #3 0x00000004 in ?? () >> #4 0x74ed1a2c in KERNEL32!GetVolumePathNamesForVolumeNameA () >> from /c/windows/syswow64/kernel32.dll >> #5 0xff11c868 in ?? () >> #6 0x74ed4208 in KERNEL32!CheckForReadOnlyResource () >> from /c/windows/syswow64/kernel32.dll >> #7 0x00000004 in ?? () >> #8 0x610d0b24 in select_stuff::wait (this=0xff11cba4, readfds=0xff11cb00, >> writefds=0xff11cae0, exceptfds=0xff11cac0, ms=4294967295) >> at >> /ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/select.cc:320 >> #9 0x610d154b in cygwin_select (maxfds=13, readfds=0xff11cc70, >> writefds=0xff11cc50, exceptfds=0xff11cc30, to=0x0) >> at >> /ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/select.cc:158 >> #10 0x610b2b5a in poll (fds=0x8012db00, nfds=3, timeout=-1) >> at >> /ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/poll.cc:87 >> #11 0x610d5575 in _sigfe () from /usr/bin/cygwin1.dll >> #12 0xffffffff in ?? () >> #13 0x8012db00 in ?? () >> #14 0x6ac1e759 in g_main_loop_run () from /usr/bin/cygglib-2.0-0.dll >> #15 0x6ad96d40 in g_dbus_proxy_call_with_unix_fd_list_sync () >> from /usr/bin/cyggio-2.0-0.dll >> #16 0x6ac401ef in g_thread_proxy () from /usr/bin/cygglib-2.0-0.dll >> #17 0x610fca42 in pthread::thread_init_wrapper (arg=0x80130e00) >> at >> /ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/thread.cc:2104 >> #18 0x61086f62 in thread_wrapper (arg=0x0) >> at >> /ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/miscfuncs.cc:547 >> #19 0x00000000 in ?? () >> >> Thread 7 (Thread 2784.0xb4c): >> #0 0x7702013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation () >> from /c/windows/SysWOW64/ntdll.dll >> #1 0x7702013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation () >> from /c/windows/SysWOW64/ntdll.dll >> #2 0x74fe0bdd in WaitForMultipleObjectsEx () >> from /c/windows/syswow64/KERNELBASE.dll >> #3 0x00000003 in ?? () >> #4 0x74ed1a2c in KERNEL32!GetVolumePathNamesForVolumeNameA () >> from /c/windows/syswow64/kernel32.dll >> #5 0xff21c858 in ?? () >> #6 0x74ed4208 in KERNEL32!CheckForReadOnlyResource () >> from /c/windows/syswow64/kernel32.dll >> #7 0x00000003 in ?? () >> #8 0x610d0b24 in select_stuff::wait (this=0xff21cb94, readfds=0xff21caf0, >> writefds=0xff21cad0, exceptfds=0xff21cab0, ms=4294967295) >> at >> /ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/select.cc:320 >> #9 0x610d154b in cygwin_select (maxfds=8, readfds=0xff21cc60, >> writefds=0xff21cc40, exceptfds=0xff21cc20, to=0x0) >> at >> /ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/select.cc:158 >> #10 0x610b2b5a in poll (fds=0x8009b3c0, nfds=1, timeout=-1) >> at >> /ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/poll.cc:87 >> #11 0x610d5575 in _sigfe () from /usr/bin/cygwin1.dll >> #12 0xffffffff in ?? () >> #13 0x8009b3c0 in ?? () >> #14 0x6ac1e759 in g_main_loop_run () from /usr/bin/cygglib-2.0-0.dll >> #15 0x63e32eca in gvdb_table_walk () >> from /usr/lib/gio/modules/cygdconfsettings.dll >> #16 0x6ac401ef in g_thread_proxy () from /usr/bin/cygglib-2.0-0.dll >> #17 0x610fca42 in pthread::thread_init_wrapper (arg=0x8009c700) >> at >> /ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/thread.cc:2104 >> #18 0x61086f62 in thread_wrapper (arg=0x0) >> at >> /ext/build/netrel/src/cygwin-snapshot-20120525-1/winsup/cygwin/miscfuncs.cc:547 >> #19 0x00000000 in ?? () >> >> It looks like these threads are being used by GLib, which is running a >> loop that calls poll, which calls cygwin_select. So maybe the "better >> patch" that you referred to would fix this hang. > > Ken, can you confirm/deny that the changes that I just made to select() > at least still work as well as Corinna's temporary (that's what the > ChangeLog says at least) change above? They are in the latest snapshot. No, they don't. There's no crash, but I'm seeing two problems in emacs and a problem with the X server. My emacs tests were done with emacs-24 in mintty on 64-bit Windows 7. I wanted to test it under X also, but I couldn't because of the X server problem. 1. When I type into emacs, it's very slow to echo the keystrokes and respond. 2. When I start a shell under emacs (shell), the shell doesn't finish initializing. It doesn't display a prompt, and it doesn't execute commands I type. 3. If I start the X server using the Start Menu shortcut, startxwin never finishes, and the xterm window doesn't display. I have to kill startxwin from a terminal. Ken -- 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