Re: cygwin-2 process handling (about SIGHUP)
On Jun 8 15:50, Marco Atzeri wrote: > On 6/8/2015 2:09 PM, Corinna Vinschen wrote: > >Hi Takashi, > > > > >You convinced me. I applied your patch. I'll generate a developer > >snapshot later today. It would be nice if it could get a thorough > >testing. > > > > > >Thanks, > >Corinna > > I am testing both 32bit and 64 bit version from yesterday > and the long trail of orphan bash processes I had before seems gone > ;-) Good news, thank you! Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpVRIR_XQFBS.pgp Description: PGP signature
Re: cygwin-2 process handling (about SIGHUP)
On 6/8/2015 2:09 PM, Corinna Vinschen wrote: Hi Takashi, You convinced me. I applied your patch. I'll generate a developer snapshot later today. It would be nice if it could get a thorough testing. Thanks, Corinna I am testing both 32bit and 64 bit version from yesterday and the long trail of orphan bash processes I had before seems gone ;-) I think my machine was specially sensible to some type of race that left bash processes around during complex builds, specially during high CPU loads. Regards Marco -- 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
Re: cygwin-2 process handling (about SIGHUP)
Hi Takashi, On Jun 7 09:03, Takashi Yano wrote: > Hi Corinna, > > On Thu, 28 May 2015 16:16:12 +0200 Corinna Vinschen wrote: > > > I applied this patch. I'm not comfortable with removing the SIGHUP > > handling from slave::read in favor of just setting errno to EIO. > > EIO seems wrong here. Not being able to access the pipe anymore > > should be equivalent to a hangup. Alternatively the return code > > from the Windows function should be checked for ERROR_BROKEN_PIPE, > > perhaps, but that introduces some more code, > > Regarding SIGHUP, I have a different thought. > [...] > To make the behaviour match with the test results on other > systems, I have made a patch attached (cygwin.patch.20150604). > > With this patch, everything works nicely for me as well. > > Furthermore, with this patch, mc (midnight commander) becomes > exiting normally. On cygwin 2.0.3-1, mc has a problem which > leaves a subshell process on the background. > > To reproduce this problem, execute > env SHELL=/bin/bash mc > on cygwin 2.0.3-1, and type 'exit'. > > You will find bash process remains in background. I have confirmed > this problem can be resolved by this patch. > > For the reason above, I think it is better to make the behaviour > match with other systems as well as the POSIX specification. > > What do you think? You convinced me. I applied your patch. I'll generate a developer snapshot later today. It would be nice if it could get a thorough testing. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpnctuvOnnFx.pgp Description: PGP signature
Re: cygwin-2 process handling (about SIGHUP)
Hi Corinna, On Thu, 28 May 2015 16:16:12 +0200 Corinna Vinschen wrote: > I applied this patch. I'm not comfortable with removing the SIGHUP > handling from slave::read in favor of just setting errno to EIO. > EIO seems wrong here. Not being able to access the pipe anymore > should be equivalent to a hangup. Alternatively the return code > from the Windows function should be checked for ERROR_BROKEN_PIPE, > perhaps, but that introduces some more code, Regarding SIGHUP, I have a different thought. I have checked the behaviour of PTY on other systems than cygwin. However, no system raises SIGHUP on the read()/write() access to PTY, of which the other side is closed. But on the close() in the master side, only when the slave side of the PTY is the controlling terminal, SIGHUP is sent to the slave side. I have tested on Debian GNU/Linux and FreeBSD as well as Cygwin. The test case is as attached (pipe_pty_test.tgz). The testing procedure is as follows. tar xzvf pipe_pty_test.tgz make make test This test case checks how the PTY behaves when the other side of the PYT is closed. As a comparison, behaviour of pipe is also tested. On Debian, the result is: Linux debian 3.16.0-4-686-pae #1 SMP Debian 3.16.7-ckt9-3~deb8u1 (2015-04-24) i686 GNU/Linux === pipe read == R: 0 read(): Success === pipe write = signal: 13 W: -1 write(): Broken pipe === pty master read MR: -1 read(): Input/output error === pty master write === MW: 11 === pty slave read = SR: -1 read(): Input/output error === pty slave write SW: -1 write(): Input/output error === pty master close === signal: 18 signal: 1 usleep(): Interrupted system call On FreeBSD, the result is: FreeBSD FreeBSD-VM 10.1-RELEASE FreeBSD 10.1-RELEASE #0 r274401: Tue Nov 11 22:51:51 UTC 2014 r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC i386 === pipe read == R: 0 read(): No error: 0 === pipe write = signal: 13 W: -1 write(): Broken pipe === pty master read MR: 0 read(): No error: 0 === pty master write === MW: 11 === pty slave read = SR: 0 read(): No error: 0 === pty slave write SW: -1 write(): Device not configured === pty master close === signal: 1 usleep(): Interrupted system call However, on cygwin, the result is: CYGWIN_NT-6.1-WOW Express5800-S70 2.0.3(0.287/5/3) 2015-06-03 13:55 i686 Cygwin === pipe read == R: 0 read(): No error === pipe write = signal: 13 W: -1 write(): Broken pipe === pty master read MR: -1 read(): Input/output error === pty master write === MW: 11 === pty slave read = signal: 1 SR: 0 read(): No error === pty slave write signal: 1 SW: -1 write(): Input/output error === pty master close === usleep(): No error On cygwin, extra SIGHUPs (signal: 1) are generated in the pty- slave-read case and in the pty-slave-write case. On the contrary, SIGHUP is not generated in the pty-master-close case while it is generated on other systems. On the Debian, SIGCONT (signal: 18) is also sent in the pty-master-close case. Although SIGHUP on the master closure was pointed out in the past: https://www.cygwin.com/ml/cygwin/2011-07/msg00328.html, it was not adopted at that time. In the track of Debian/FreeBSD, SIGHUP should not be generated on the read()/write() access on the slave side, but should be generated on the close() on the master side, only when the slave side of the PTY is the controlling terminal. It seems that this behaviour is specified in the POSIX standard. http://pubs.opengroup.org/onlinepubs/9699919799/functions/close.html To make the behaviour match with the test results on other systems, I have made a patch attached (cygwin.patch.20150604). With this patch, everything works nicely for me as well. Furthermore, with this patch, mc (midnight commander) becomes exiting normally. On cygwin 2.0.3-1, mc has a problem which leaves a subshell process on the background. To reproduce this problem, execute env SHELL=/bin/bash mc on cygwin 2.0.3-1, and type 'exit'. You will find bash process remains in background. I have confirmed this problem can be resolved by this patch. For the reason above, I think it is better to make the behaviour match with other systems as well as the POSIX specification. What do you think? ChangeLog is as follows. 2015-06-04 Takashi Yano * fhandler_tty.cc (fhandler_pty_slave::write): Move causing of SIGHUP into fhandler_pty_master::close(). (fhandler_pty_slave::read): Ditto. (fhandler_pty_master::close): Ditto. -- Takashi Yano pipe_pty_test.tgz Description: GNU Unix tar archive cygwin.patch.20150604 Description: Binary data -- 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
Re: cygwin-2 process handling
Hi Takashi, On May 28 21:44, Takashi Yano wrote: > Hi Corinna, > > On Thu, 28 May 2015 21:09:32 +0900 > Takashi Yano wrote: > > > On Thu, 28 May 2015 13:47:28 +0200 > > Corinna Vinschen wrote: > > > > > I created another version of your patch which avoids duplicating the > > > tested handle and makes the test-and-close-handle operation atomic: > > > > > Does that look ok? It fixes the reported problem for me. > > > > Oops! I have just sent another patch. > > Your patch also works nicely for me. I applied this patch. I'm not comfortable with removing the SIGHUP handling from slave::read in favor of just setting errno to EIO. EIO seems wrong here. Not being able to access the pipe anymore should be equivalent to a hangup. Alternatively the return code from the Windows function should be checked for ERROR_BROKEN_PIPE, perhaps, but that introduces some more code, Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp1dAoNvq0cx.pgp Description: PGP signature
Re: cygwin-2 process handling
Hi Corinna, On Thu, 28 May 2015 21:09:32 +0900 Takashi Yano wrote: > On Thu, 28 May 2015 13:47:28 +0200 > Corinna Vinschen wrote: > > > I created another version of your patch which avoids duplicating the > > tested handle and makes the test-and-close-handle operation atomic: > > > Does that look ok? It fixes the reported problem for me. > > Oops! I have just sent another patch. Your patch also works nicely for me. -- Takashi Yano -- 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
Re: cygwin-2 process handling
On Thu, 28 May 2015 13:47:28 +0200 Corinna Vinschen wrote: > I created another version of your patch which avoids duplicating the > tested handle and makes the test-and-close-handle operation atomic: > Does that look ok? It fixes the reported problem for me. Oops! I have just sent another patch. -- Takashi Yano -- 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
Re: cygwin-2 process handling
Hi Corinna, On Wed, 27 May 2015 14:23:12 +0200 Corinna Vinschen wrote: > Isn't that racy? Consider two processes doing that at the same time. > Both calls to NtQueryObject could come up with hdl_cnt == 2 and the > problem persists. Yes, indeed. I didn't consider enough. > Wouldn't it be safer to call SetEvent(input_available_event) all the > time from here? On Wed, 27 May 2015 17:17:34 +0200 Corinna Vinschen wrote: > We discussed this already in March and only briefly talked about a > change like this requiring changes to fhandler_pty_slave::read. > However, I don't see this. The read code already takes 0 bytes input > and broken pipe scenarios into account. Do you see something needing > a change I don't? Just calling SetEvent(input_available_event) at all time in fhandler_pty_master::close() causes immediate closure of the shell on pty at the start. Some modifications in fhandler_pty_slave::read() seems necessary. I have made a patch attached, which modifies fhandler_pty_slave:: read() as well. I have not confirmed enough yet, but it seems to work for me. Please have a look. -- Takashi Yano cygwin.patch.20150528 Description: Binary data -- 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
Re: cygwin-2 process handling
On May 27 17:17, Corinna Vinschen wrote:
> On May 27 14:23, Corinna Vinschen wrote:
> > Hi Takashi,
> >
> > On May 21 20:53, Takashi Yano wrote:
> > > [...]
> > > + if (output_handle_local)
> > > +{
> > > + OBJECT_BASIC_INFORMATION obi;
> > > + NTSTATUS status;
> > > + ULONG hdl_cnt = 0;
> > > +
> > > + status = NtQueryObject (output_handle_local,
> > > ObjectBasicInformation,
> > > + &obi, sizeof obi, NULL);
> > > + if (!NT_SUCCESS (status))
> > > + debug_printf ("NtQueryObject: %y", status);
> > > + else
> > > + hdl_cnt = obi.HandleCount;
> > > + termios_printf("HandleCount: %d", hdl_cnt);
> > > + if (hdl_cnt == 1)
> > > + SetEvent (input_available_event);
> > > + CloseHandle (output_handle_local);
> > > +}
> >
> > Isn't that racy? Consider two processes doing that at the same time.
> > Both calls to NtQueryObject could come up with hdl_cnt == 2 and the
> > problem persists.
> >
> > Wouldn't it be safer to call SetEvent(input_available_event) all the
> > time from here?
>
> We discussed this already in March and only briefly talked about a
> change like this requiring changes to fhandler_pty_slave::read.
> However, I don't see this. The read code already takes 0 bytes input
> and broken pipe scenarios into account. Do you see something needing
> a change I don't?
Never mind, it doesn't work quite as expected, so changes would be
required.
I created another version of your patch which avoids duplicating the
tested handle and makes the test-and-close-handle operation atomic:
* fhandler_tty.cc (fhandler_pty_common::close): Don't close output_mutex
here. Move into callers.
(fhandler_pty_master::close): Use NtQueryObject instead of
PeekNamedPipe to detect closing the last master handle.
diff --git a/winsup/cygwin/fhandler_tty.cc b/winsup/cygwin/fhandler_tty.cc
index e91b3e3..12f6124 100644
--- a/winsup/cygwin/fhandler_tty.cc
+++ b/winsup/cygwin/fhandler_tty.cc
@@ -552,7 +552,10 @@ fhandler_pty_slave::close ()
get_output_handle_cyg ());
if ((unsigned) myself->ctty == FHDEV (DEV_PTYS_MAJOR, get_minor ()))
fhandler_console::free_console (); /* assumes that we are the last pty
closer */
- return fhandler_pty_common::close ();
+ fhandler_pty_common::close ();
+ if (!ForceCloseHandle (output_mutex))
+termios_printf ("CloseHandle (output_mutex<%p>), %E", output_mutex);
+ return 0;
}
int
@@ -1259,8 +1262,6 @@ fhandler_pty_common::close ()
termios_printf ("pty%d <%p,%p> closing", get_minor (), get_handle (),
get_output_handle ());
if (!ForceCloseHandle (input_mutex))
termios_printf ("CloseHandle (input_mutex<%p>), %E", input_mutex);
- if (!ForceCloseHandle (output_mutex))
-termios_printf ("CloseHandle (output_mutex<%p>), %E", output_mutex);
if (!ForceCloseHandle1 (get_handle (), from_pty))
termios_printf ("CloseHandle (get_handle ()<%p>), %E", get_handle ());
if (!ForceCloseHandle1 (get_output_handle (), to_pty))
@@ -1281,6 +1282,9 @@ fhandler_pty_master::cleanup ()
int
fhandler_pty_master::close ()
{
+ OBJECT_BASIC_INFORMATION obi;
+ NTSTATUS status;
+
termios_printf ("closing from_master(%p)/to_master(%p)/to_master_cyg(%p)
since we own them(%u)",
from_master, to_master, to_master_cyg, dwProcessId);
if (cygwin_finished_initializing)
@@ -1309,13 +1313,22 @@ fhandler_pty_master::close ()
}
}
- fhandler_pty_common::close ();
-
/* Check if the last master handle has been closed. If so, set
input_available_event to wake up potentially waiting slaves. */
- if (!PeekNamedPipe (from_master, NULL, 0, NULL, NULL, NULL)
- && GetLastError () == ERROR_BROKEN_PIPE)
-SetEvent (input_available_event);
+ acquire_output_mutex (INFINITE);
+ status = NtQueryObject (get_output_handle (), ObjectBasicInformation,
+ &obi, sizeof obi, NULL);
+ fhandler_pty_common::close ();
+ release_output_mutex ();
+ if (!ForceCloseHandle (output_mutex))
+termios_printf ("CloseHandle (output_mutex<%p>), %E", output_mutex);
+ if (!NT_SUCCESS (status))
+debug_printf ("NtQueryObject: %y", status);
+ else if (obi.HandleCount == 1)
+{
+ termios_printf("Closing last master");
+ SetEvent (input_available_event);
+}
if (!ForceCloseHandle (from_master))
termios_printf ("error closing from_master %p, %E", from_master);
Does that look ok? It fixes the reported problem for me.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgp2AtKGtAz0B.pgp
Description: PGP signature
Re: cygwin-2 process handling
On May 27 14:23, Corinna Vinschen wrote:
> Hi Takashi,
>
> On May 21 20:53, Takashi Yano wrote:
> > [...]
> > + if (output_handle_local)
> > +{
> > + OBJECT_BASIC_INFORMATION obi;
> > + NTSTATUS status;
> > + ULONG hdl_cnt = 0;
> > +
> > + status = NtQueryObject (output_handle_local, ObjectBasicInformation,
> > + &obi, sizeof obi, NULL);
> > + if (!NT_SUCCESS (status))
> > + debug_printf ("NtQueryObject: %y", status);
> > + else
> > + hdl_cnt = obi.HandleCount;
> > + termios_printf("HandleCount: %d", hdl_cnt);
> > + if (hdl_cnt == 1)
> > + SetEvent (input_available_event);
> > + CloseHandle (output_handle_local);
> > +}
>
> Isn't that racy? Consider two processes doing that at the same time.
> Both calls to NtQueryObject could come up with hdl_cnt == 2 and the
> problem persists.
>
> Wouldn't it be safer to call SetEvent(input_available_event) all the
> time from here?
We discussed this already in March and only briefly talked about a
change like this requiring changes to fhandler_pty_slave::read.
However, I don't see this. The read code already takes 0 bytes input
and broken pipe scenarios into account. Do you see something needing
a change I don't?
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgpCmxQQ3JC5J.pgp
Description: PGP signature
Re: cygwin-2 process handling
Hi Takashi,
On May 21 20:53, Takashi Yano wrote:
> [...]
> I was looking into this problem, and found the PeekNamedPipe()
> call is blocked in fhandler_pty_master::close() when the problem
> occurs.
>
> I had not noticed that,
>
> https://msdn.microsoft.com/en-us/library/windows/desktop/aa365779(v=vs.85).aspx
>
> says:
> > The PeekNamedPipe function can block thread execution the same
> > way any I/O function can when called on a synchronous handle in
> > a multi-threaded application.
>
> I have made a patch attached to resolve this problem. Please have
> a look.
>
> With this patch, NtQueryObject() is used instead of PeekNamedPipe()
> to detect closure of the last master handle.
>
> Please refer to the following discussion for more details.
> http://cygwin.com/ml/cygwin/2015-03/msg00221.html
>
>
> ChageLog is as follows.
>
> 2015-05-21 Takashi Yano <...>
>
> * fhandler_tty.cc (fhandler_pty_master::close): Use NtQueryObject()
> instead of PeekNamedPipe() to detect closing the last master handle.
> [...]
> + if (output_handle_local)
> +{
> + OBJECT_BASIC_INFORMATION obi;
> + NTSTATUS status;
> + ULONG hdl_cnt = 0;
> +
> + status = NtQueryObject (output_handle_local, ObjectBasicInformation,
> + &obi, sizeof obi, NULL);
> + if (!NT_SUCCESS (status))
> + debug_printf ("NtQueryObject: %y", status);
> + else
> + hdl_cnt = obi.HandleCount;
> + termios_printf("HandleCount: %d", hdl_cnt);
> + if (hdl_cnt == 1)
> + SetEvent (input_available_event);
> + CloseHandle (output_handle_local);
> +}
Isn't that racy? Consider two processes doing that at the same time.
Both calls to NtQueryObject could come up with hdl_cnt == 2 and the
problem persists.
Wouldn't it be safer to call SetEvent(input_available_event) all the
time from here?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgpoMru9z3zmd.pgp
Description: PGP signature
Re: cygwin-2 process handling
Ken Brown said: > Takashi Yano wrote: >> >> I have made a patch attached to resolve this problem. Please have >> a look. >> > > Thanks! That fixes it for me. Michael (OP), are you able to build cygwin1.dll > and test it? > > > Ken Unfortunately, I don't have the ability to build a new cygwin.dll on my work laptop. I'll have to rely upon your testing, but since you were able to replicate my symptoms and the problem can be traced to a specific change and a documented behavior, I'm feeling pretty confident in the patch. Thanks for your effort on this. MICHAEL MAUGER // FSF Member // GNU Emacs sql-mode maintainer // GNU Linux, GNU Emacs, OwnCloud -- 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
Re: cygwin-2 process handling
Hi Takashi, On 5/21/2015 7:53 AM, Takashi Yano wrote: I was looking into this problem, and found the PeekNamedPipe() call is blocked in fhandler_pty_master::close() when the problem occurs. I had not noticed that, https://msdn.microsoft.com/en-us/library/windows/desktop/aa365779(v=vs.85).aspx says: The PeekNamedPipe function can block thread execution the same way any I/O function can when called on a synchronous handle in a multi-threaded application. I have made a patch attached to resolve this problem. Please have a look. Thanks! That fixes it for me. Michael (OP), are you able to build cygwin1.dll and test it? 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
Re: cygwin-2 process handling
Hi Ken, On Tue, 19 May 2015 14:16:35 -0400 Ken Brown wrote: > OK, I got the bisection to work: > > 32fd5b0fe1548cff79b9868e4e259853c59a44db is the first bad commit > commit 32fd5b0fe1548cff79b9868e4e259853c59a44db > Author: Takashi Yano > Date: Thu Mar 12 15:48:10 2015 +0100 > > Let pty slave detect closure of last master handle > > * fhandler_tty.cc (fhandler_pty_master::close): Add code to > make slave > detect closure of master. Fix typo in error message. > > > Takashi, can you help? If not, we'll have to wait for Corinna to get > back from vacation. I was looking into this problem, and found the PeekNamedPipe() call is blocked in fhandler_pty_master::close() when the problem occurs. I had not noticed that, https://msdn.microsoft.com/en-us/library/windows/desktop/aa365779(v=vs.85).aspx says: > The PeekNamedPipe function can block thread execution the same > way any I/O function can when called on a synchronous handle in > a multi-threaded application. I have made a patch attached to resolve this problem. Please have a look. With this patch, NtQueryObject() is used instead of PeekNamedPipe() to detect closure of the last master handle. Please refer to the following discussion for more details. http://cygwin.com/ml/cygwin/2015-03/msg00221.html ChageLog is as follows. 2015-05-21 Takashi Yano * fhandler_tty.cc (fhandler_pty_master::close): Use NtQueryObject() instead of PeekNamedPipe() to detect closing the last master handle. -- Takashi Yano cygwin.patch.20150521 Description: Binary data -- 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
Re: cygwin-2 process handling
On 5/19/2015 1:14 PM, Ken Brown wrote: On 5/18/2015 1:15 PM, Michael Mauger wrote: Since the upgrade to cygwin-2 I've been having consistent problems using emacs. My emacs config has not changed and the most recent update to cygwin-2 has helped. I'm using the emacs-w32 executable and have numerous remote cygwin ssh sessions running underneath emacs so that I can edit remote files and run remote shell sessions within emacs. When I then start up a Windows console executable (in my case Oracles sqlplus.exe, but cmd.exe works too), I start getting hanging in the cygwin ssh sessions. Filename completion (which involves emacs interacting with a ssh session) or opening a remote file (which involves emacs transferring the file locally via scp or inline) will both hang. It generally requires that I send a SIGUSR2 signal to the emacs-w32 process which emacs responds to by halting whatever is running and returning to the top level interaction loop. When it does so, the process appears to be waiting for input. If I then end the console session, the interaction returns to normal. Trying to start a second Windows console session will also hang. In Emacs *scratch* buffer (shell "*One*") C-j # (shell "*Two*") C-j # (let ((explicit-shell-file-name "/c/Windows/System32/cmd.exe")) (shell "*Three*")) C-j # (let ((explicit-shell-file-name "/c/Windows/System32/cmd.exe")) (shell "*Four*")) C-j *** HANGS *** I can reproduce this, and even more simply. If I start a single shell running cmd.exe, then emacs hangs on the next attempt to call a subprocess. For example, I first evaluate the following in the *scratch* buffer (let ((explicit-shell-file-name "/c/Windows/System32/cmd.exe")) (shell)) I then try to list a directory with 'C-x d', and emacs hangs. The problem appears in the 2015-03-17 cygwin snapshot but not in the 2015-03-11 snapshot. I'm trying to do a git bisection to narrow it down further, but so far I haven't succeeded because I get errors when I try to build the git checkouts from around that time. I'll keep trying. OK, I got the bisection to work: 32fd5b0fe1548cff79b9868e4e259853c59a44db is the first bad commit commit 32fd5b0fe1548cff79b9868e4e259853c59a44db Author: Takashi Yano Date: Thu Mar 12 15:48:10 2015 +0100 Let pty slave detect closure of last master handle * fhandler_tty.cc (fhandler_pty_master::close): Add code to make slave detect closure of master. Fix typo in error message. Takashi, can you help? If not, we'll have to wait for Corinna to get back from vacation. 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
Re: cygwin-2 process handling
On 5/18/2015 1:15 PM, Michael Mauger wrote: Since the upgrade to cygwin-2 I've been having consistent problems using emacs. My emacs config has not changed and the most recent update to cygwin-2 has helped. I'm using the emacs-w32 executable and have numerous remote cygwin ssh sessions running underneath emacs so that I can edit remote files and run remote shell sessions within emacs. When I then start up a Windows console executable (in my case Oracles sqlplus.exe, but cmd.exe works too), I start getting hanging in the cygwin ssh sessions. Filename completion (which involves emacs interacting with a ssh session) or opening a remote file (which involves emacs transferring the file locally via scp or inline) will both hang. It generally requires that I send a SIGUSR2 signal to the emacs-w32 process which emacs responds to by halting whatever is running and returning to the top level interaction loop. When it does so, the process appears to be waiting for input. If I then end the console session, the interaction returns to normal. Trying to start a second Windows console session will also hang. In Emacs *scratch* buffer (shell "*One*") C-j # (shell "*Two*") C-j # (let ((explicit-shell-file-name "/c/Windows/System32/cmd.exe")) (shell "*Three*")) C-j # (let ((explicit-shell-file-name "/c/Windows/System32/cmd.exe")) (shell "*Four*")) C-j *** HANGS *** I can reproduce this, and even more simply. If I start a single shell running cmd.exe, then emacs hangs on the next attempt to call a subprocess. For example, I first evaluate the following in the *scratch* buffer (let ((explicit-shell-file-name "/c/Windows/System32/cmd.exe")) (shell)) I then try to list a directory with 'C-x d', and emacs hangs. The problem appears in the 2015-03-17 cygwin snapshot but not in the 2015-03-11 snapshot. I'm trying to do a git bisection to narrow it down further, but so far I haven't succeeded because I get errors when I try to build the git checkouts from around that time. I'll keep trying. 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
