[Mono-bugs] [Bug 64419][Maj] New - System.IO.File.Open deadlocks

[bugzilla-daemon@bugzilla.ximian.com]

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 banderso@novell.com.

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

--- shadow/64419	2004-08-27 22:00:26.000000000 -0400
+++ shadow/64419.tmp.23947	2004-08-27 22:00:26.000000000 -0400
@@ -0,0 +1,45 @@
+Bug#: 64419
+Product: Mono: Class Libraries
+Version: unspecified
+OS: 
+OS Details: NLD 1.6 (SLES9 core)
+Status: NEW   
+Resolution: 
+Severity: 008 One day
+Priority: Major
+Component: System
+AssignedTo: mono-bugs@ximian.com                            
+ReportedBy: banderso@novell.com               
+QAContact: mono-bugs@ximian.com
+TargetMilestone: ---
+URL: 
+Cc: 
+Summary: System.IO.File.Open deadlocks
+
+Description of Problem:
+The iFolder team implemented a shared mutex by opening a known file and
+setting the FileShare to "None".  This mutex is hit by multiple threads
+within multiple processes.  After running for 4-10 hours, all threads will
+deadlock on the file open method.  Exactly three hours later Mono releases
+all threads.  We have seen this time and time again in our log files (the
+three hour release).  The open close sequence is surrounded by a Try
+Finally so we should never leave the sequence without closing the file. 
+Once this happens we usually have to delete the .wapi file to get our
+server running again.
+
+Steps to reproduce the problem:
+1. 
+2. 
+3. 
+
+Actual Results:
+
+
+Expected Results:
+
+
+How often does this happen? 
+usually around 10 hours with three processes and 2-3 threads in each process.
+
+Additional Information:
+At this time, I don't have a test program to reproduce the problem.