[Mono-bugs] [Bug 75733][Nor] New - The io-layer sometimes creates handles with a value of NULL

bugzilla-daemon at bugzilla.ximian.com bugzilla-daemon at bugzilla.ximian.com
Sat Aug 6 14:05:36 EDT 2005

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 lluis at ximian.com.


--- shadow/75733	2005-08-06 14:05:36.000000000 -0400
+++ shadow/75733.tmp.5349	2005-08-06 14:05:36.000000000 -0400
@@ -0,0 +1,37 @@
+Bug#: 75733
+Product: Mono: Runtime
+Version: 1.1
+OS: NLD 9
+OS Details: 
+Status: NEW   
+Priority: Normal
+Component: io-layer
+AssignedTo: mono-bugs at ximian.com                            
+ReportedBy: lluis at ximian.com               
+QAContact: mono-bugs at ximian.com
+TargetMilestone: ---
+Summary: The io-layer sometimes creates handles with a value of NULL
+I found this problem while tracking down a failure in MonoDevelop when
+starting a process. In some cases, this call in io.c:
+	ret=pipe (filedes);
+returns in filedes a file descriptor with the value zero. The return value
+ret is != -1, so I guess that zero is a valid value for a file descriptor.
+However, the call to _wapi_handle_new_fd() returns NULL for this fd (since
+it just returns GUINT_TO_POINTER(fd)), and I think this is not correct
+because NULL should not be a valid value for a handle (at least, it is not
+in WIN32).
+The process later fails to start because in process.c:857 there is a call
+to CloseHandle(procinfo.hThread), and procinfo.hThread happens to be
+initialized to NULL, and this accidentally closes the pipe.
+My particular problem can be solved by removing that CloseHandle call
+(which is useless right now), although I think something must be done to
+avoid returning null handles.

More information about the mono-bugs mailing list