select() hanging after terminal killed

select() hanging after terminal killed

[Thomas Wolff]

If a terminal gets killed, its tty/pty is not properly closed.
This is likely to confuse applications and let them hang, as observed 
with mined (thanks Andy for the report) and joe.

On Linux and SunOS, a subsequent read() return 0 (indicating EOF);
any further read() returns -1, errno indicating EIO.
Immediate write() may report success a few times, 
further write() returns -1, errno indicating EIO.

On Linux, select() indicates an exception and EIO.
On SunOS, select() indicates both an exception and input (weird),
and ENOENT initially, EIO on further attempts.

On Cygwin, the following is observed:
* EOF is not signalled on read(); rather EIO is indicated right away.
  (Maybe not too bad, an application can handle that as well.)
* select() with timeout hangs.

Especially the latter can hardly be handled by an application.

------
Thomas

--
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: select() hanging after terminal killed

[Matthias Andree]

Am 29.04.2010 12:53, schrieb Thomas Wolff:

[on closed terminal]
> On Linux, select() indicates an exception and EIO.
> On SunOS, select() indicates both an exception and input (weird),

Not weird, you appear to be misunderstanding select().
An IEEE Std 1003.1 compliant select():

 - only states that a subsequent read() will *not block*
   this includes EOF and error, as they make read() return without blocking)

 - makes *no statements about success*

> On Cygwin, the following is observed:
> * EOF is not signalled on read(); rather EIO is indicated right away.
>   (Maybe not too bad, an application can handle that as well.)
> * select() with timeout hangs.
> 
> Especially the latter can hardly be handled by an application.

Pointers for workarounds: alarm(), signal().

-- 
Matthias Andree

--
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: select() hanging after terminal killed

[Thomas Wolff]

On 29.04.2010 13:28, Matthias Andree wrote:
> Am 29.04.2010 12:53, schrieb Thomas Wolff:
>
> [on closed terminal]
>    
>> On Linux, select() indicates an exception and EIO.
>> On SunOS, select() indicates both an exception and input (weird),
>>      
> Not weird, you appear to be misunderstanding select().
> An IEEE Std 1003.1 compliant select():
>
>   - only states that a subsequent read() will *not block*
>     this includes EOF and error, as they make read() return without blocking)
>
>   - makes *no statements about success*
>    
Oh, right, so apparently Linux is wrong here (since it does not report 
read availability...).

>> On Cygwin, the following is observed:
>> * EOF is not signalled on read(); rather EIO is indicated right away.
>>    (Maybe not too bad, an application can handle that as well.)
>> * select() with timeout hangs.
>>
>> Especially the latter can hardly be handled by an application.
>>      
> Pointers for workarounds: alarm(), signal().
>    
So I could setup alarm() to get myself signal()ed while waiting in a 
long sleep().
But the granularity is in seconds only, so this is not a substitute for 
most use cases typically handled by calling select().
Thanks for the information anyway.

------
Thomas

--
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: select() hanging after terminal killed

[Matthias Andree]

Thomas Wolff wrote on 2010-04-29:

> On 29.04.2010 13:28, Matthias Andree wrote:
>> Am 29.04.2010 12:53, schrieb Thomas Wolff:
>>
>> [on closed terminal]
>>
>>> On Linux, select() indicates an exception and EIO.
>>> On SunOS, select() indicates both an exception and input (weird),
>>>
>> Not weird, you appear to be misunderstanding select().
>> An IEEE Std 1003.1 compliant select():
>>
>>   - only states that a subsequent read() will *not block*
>>     this includes EOF and error, as they make read() return without  
>> blocking)
>>
>>   - makes *no statements about success*
>>
> Oh, right, so apparently Linux is wrong here (since it does not report  
> read availability...).

Arguably yes, probably an omission in your system. (Note that older POSIX  
versions didn't specify that errors means readability).

Please look if a relevant bug is filed, and if not, please do so.

>>> On Cygwin, the following is observed:
>>> * EOF is not signalled on read(); rather EIO is indicated right away.
>>>    (Maybe not too bad, an application can handle that as well.)
>>> * select() with timeout hangs.
>>>
>>> Especially the latter can hardly be handled by an application.
>>>
>> Pointers for workarounds: alarm(), signal().
>>
> So I could setup alarm() to get myself signal()ed while waiting in a  
> long sleep().
> But the granularity is in seconds only, so this is not a substitute for  
> most use cases typically handled by calling select().
> Thanks for the information anyway.

Rather than discussing the downsides, you might more efficiently just read  
the standard, or the system documentation, which would then point you to  
setitimer().

-- 
Matthias Andree

--
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: select() hanging after terminal killed

[Corinna Vinschen]

On Apr 29 12:53, Thomas Wolff wrote:
> If a terminal gets killed, its tty/pty is not properly closed.
> This is likely to confuse applications and let them hang, as observed 
> with mined (thanks Andy for the report) and joe.
> 
> On Linux and SunOS, a subsequent read() return 0 (indicating EOF);
> any further read() returns -1, errno indicating EIO.
> Immediate write() may report success a few times, 
> further write() returns -1, errno indicating EIO.
> 
> On Linux, select() indicates an exception and EIO.
> On SunOS, select() indicates both an exception and input (weird),
> and ENOENT initially, EIO on further attempts.
> 
> On Cygwin, the following is observed:
> * EOF is not signalled on read(); rather EIO is indicated right away.
>   (Maybe not too bad, an application can handle that as well.)
> * select() with timeout hangs.
> 
> Especially the latter can hardly be handled by an application.

Can you create a simple testcase?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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: select() hanging after terminal killed

[Christopher Faylor]

On Thu, Apr 29, 2010 at 05:11:00PM +0200, Corinna Vinschen wrote:
>On Apr 29 12:53, Thomas Wolff wrote:
>> If a terminal gets killed, its tty/pty is not properly closed.
>> This is likely to confuse applications and let them hang, as observed 
>> with mined (thanks Andy for the report) and joe.
>> 
>> On Linux and SunOS, a subsequent read() return 0 (indicating EOF);
>> any further read() returns -1, errno indicating EIO.
>> Immediate write() may report success a few times, 
>> further write() returns -1, errno indicating EIO.
>> 
>> On Linux, select() indicates an exception and EIO.
>> On SunOS, select() indicates both an exception and input (weird),
>> and ENOENT initially, EIO on further attempts.
>> 
>> On Cygwin, the following is observed:
>> * EOF is not signalled on read(); rather EIO is indicated right away.
>>   (Maybe not too bad, an application can handle that as well.)
>> * select() with timeout hangs.
>> 
>> Especially the latter can hardly be handled by an application.
>
>Can you create a simple testcase?

Hmm.  Since the owner has both sides of the pipe open maybe closing the
slave side doesn't trigger select.

It's possible that Corinna's changes to tty handling might make this
work better.  It would be interesting to see how this works in a recent
snapshot.

cgf

--
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: select() hanging after terminal killed

[Thomas Wolff]

[-- Attachment #1: Type: text/plain, Size: 1653 bytes --]

On 29.04.2010 17:21, Christopher Faylor wrote:
> On Thu, Apr 29, 2010 at 05:11:00PM +0200, Corinna Vinschen wrote:
>> On Apr 29 12:53, Thomas Wolff wrote:
>>> If a terminal gets killed, its tty/pty is not properly closed.
>>> This is likely to confuse applications and let them hang, as observed
>>> with mined (thanks Andy for the report) and joe.
>>>
>>> On Linux and SunOS, a subsequent read() return 0 (indicating EOF);
>>> any further read() returns -1, errno indicating EIO.
>>> Immediate write() may report success a few times,
>>> further write() returns -1, errno indicating EIO.
>>>
>>> On Linux, select() indicates an exception and EIO.
>>> On SunOS, select() indicates both an exception and input (weird),
>>> and ENOENT initially, EIO on further attempts.
>>>
>>> On Cygwin, the following is observed:
>>> * EOF is not signalled on read(); rather EIO is indicated right away.
>>>    (Maybe not too bad, an application can handle that as well.)
>>> * select() with timeout hangs.
>>>
>>> Especially the latter can hardly be handled by an application.
>> Can you create a simple testcase?
I finally managed it... (attached).
In a mintty or xterm, run hupsel > /dev/tty... (some other terminal to 
observe).
Then close the terminal (click on 'X' corner).
On Linux, the program terminates.
On cygwin, the program hangs in select().

> Hmm.  Since the owner has both sides of the pipe open maybe closing the
> slave side doesn't trigger select.
>
> It's possible that Corinna's changes to tty handling might make this
> work better.  It would be interesting to see how this works in a recent
> snapshot.
Unfortunately not.

Kind regards,
Thomas

[-- Attachment #2: hupsel.c --]
[-- Type: text/plain, Size: 1123 bytes --]

#include <stdio.h>
#include <stdlib.h>

#include <sys/select.h>
#include <errno.h>

#include <signal.h>

int
peek (int fd, int msec)
{
	fd_set readfds;
	fd_set exceptfds;
	struct timeval timeoutstru;

	FD_ZERO (& readfds);
	FD_SET (fd, & readfds);
	FD_ZERO (& exceptfds);
	FD_SET (fd, & exceptfds);
	timeoutstru.tv_sec = msec / 1000;
	timeoutstru.tv_usec = (msec % 1000) * 1000;

	errno = 0;
	printf ("calling select\n");
	int nfds = select (fd + 1, & readfds, 0, & exceptfds, & timeoutstru);
	printf ("select -> %d (%s), read %02X except %02X\n", 
		nfds, strerror (errno), readfds, exceptfds);

	return nfds;
}

void
catch_HUP (int hup)
{
	printf ("HUP\n");
	signal (SIGHUP, catch_HUP);
}

int
main ()
{
	int fdstdin = 0;

	system ("stty cbreak");
	signal (SIGHUP, catch_HUP);

	while (1) {
		char buf;
		int buflen = 1;

		int nfds = peek (fdstdin, 1500);
		if (nfds > 0) {
			printf ("calling read\n");
			errno = 0;
			int n = read (fdstdin, & buf, buflen);
			if (n <= 0) {
				printf ("read -> %d (%s); exit\n", n, strerror (errno));
				exit (0);
			}
			printf ("read -> %d: %c\n", n, buf);
		}
		sleep (2);
	}
}


[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

--
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