[Mono-bugs] [Bug 74840][Maj] New - Blocking Read() does not return if NetworkStream is closed underneath it

bugzilla-daemon@bugzilla.ximian.com bugzilla-daemon@bugzilla.ximian.com
Thu, 5 May 2005 15:46:01 -0400 (EDT)


Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by joeshaw@novell.com.

http://bugzilla.ximian.com/show_bug.cgi?id=74840

--- shadow/74840	2005-05-05 15:46:00.000000000 -0400
+++ shadow/74840.tmp.30327	2005-05-05 15:46:00.000000000 -0400
@@ -0,0 +1,32 @@
+Bug#: 74840
+Product: Mono: Class Libraries
+Version: 1.1
+OS: 
+OS Details: 
+Status: NEW   
+Resolution: 
+Severity: 
+Priority: Major
+Component: CORLIB
+AssignedTo: mono-bugs@ximian.com                            
+ReportedBy: joeshaw@novell.com               
+QAContact: mono-bugs@ximian.com
+TargetMilestone: ---
+URL: 
+Cc: 
+Summary: Blocking Read() does not return if NetworkStream is closed underneath it
+
+If in one thread you are doing a blocking Read() on a NetworkStream and in
+another thread you close the stream, I would expect that the connection
+would be closed and the Read() would return 0 bytes read.  Instead, the
+connection stays open and continues to block, and if the client sends any
+data exceptions are thrown.
+
+I'm attaching a test case.  Run it and connect to it using telnet on port
+8888 as soon as it starts.  10 seconds after it starts it will call Close()
+on the TcpClient (or UnixClient), which in turn closes the NetworkStream
+underneath it.  Notice on the server side that it does not say "Read 0
+bytes", meaning that the Read() call is still blocking.  Also notice on the
+client side that the connection has not been disconnected.  Type anything
+in on the client side after the connection has been "closed" and you'll see
+exceptions on the server side.