From: wyvern@gnu.ai.mit.edu (The Wyvern) Subject: Re: [Q] Bug in select(2)? Date: Wed, 16 Dec 1992 08:25:53 GMT
In article <10DEC199211081583@addvax.llnl.gov> brand@addvax.llnl.gov (Hal R. Brand, LLnL, 510-422-6312) writes:
>I just tried to get the Diku client TINTIN running under Linux. With just a
>little futzing, it compiled and fired up printing its banner and prompt.
>However, upon typing the first character, TINTIN aborted due to an error in
>read(2) on fd 0; the error was errno=4, Interrupted system call. After some
>playing, I was able to isolate what I think is the problem: select(2) returns
>that fd 0 has input ready immediately following the typing of the first
>character, but read(2) on fd 0 blocks until the whole line is available (i.e.
>until you hit the <return> key). When TINTIN's timer (via alarm(3)) goes off,
>the (blocking) read(2) returns with and error and errno set to 4. The program
>below demonstrates the problem. Under Ultrix and SunOS, I never get any "I"s
>printed ("I"s indicate that "read(0,...)" was blocking when the SIGALRM was
>delivered). But, under Linux, I get the "I"s after every SIGALRM (indicated
>by a "T" being printed) following typing the first character of input.
>
>Is there something special about the Linux select(2), or read(2), or
>possibly the mode BASH leaves the terminal driver in that I don't know about,
>or have I misinterpreted the data, or is it a bug?
>
>Hardware Config:
> 486-50 (OPTI) with 8 Mybte
> Maxtor 130 Mbyte
> Part. 1 is 64 Mybte DOS
> Part. 2 is 8 Mbyte Linux swap
> Part. 3 is 64 Mbyte Linux/Minix fs
> NO ethernet board
>Software Config:
> Latest SLS (a,b,c,x)
>
> Hal R. Brand
> LLNL
> brand@addvax.llnl.gov
I've also been noticing some strange behavior which seems to be also due to
select(2), although it doesn't seem to be of the same type as mentioned
above. I'm running a client/server program that uses sockets of type AF_INET.
Up until 0.99 I wasn't having problems but now clients and servers are getting
stuck. They just hang. ps -l shows the WCHAN for the hung processes as
tcp_read
when normally it shows do_select when they're working correctly. The programs
work for an indefinite period of time before locking up completely, at which point
I have to kill the processes and restart them.
System configuration:
486-33 8mb RAM
200 mb IDE hd
Linux v0.99 with TCP/IP
also no ethernet board