[Mono-bugs] [Bug 61644][Blo] New - Mixed up state using shared resources in Mono

bugzilla-daemon@bugzilla.ximian.com bugzilla-daemon@bugzilla.ximian.com
Thu, 15 Jul 2004 17:15:23 -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 banderso@novell.com.


--- shadow/61644	2004-07-15 17:15:23.000000000 -0400
+++ shadow/61644.tmp.19204	2004-07-15 17:15:23.000000000 -0400
@@ -0,0 +1,55 @@
+Bug#: 61644
+Product: Mono: Runtime
+Version: unspecified
+OS Details: Novell Linux Desktop Beta 1
+Status: NEW   
+Severity: 001 One hour
+Priority: Blocker
+Component: misc
+AssignedTo: mono-bugs@ximian.com                            
+ReportedBy: banderso@novell.com               
+QAContact: mono-bugs@ximian.com
+TargetMilestone: ---
+Summary: Mixed up state using shared resources in Mono
+Please fill in this template when reporting a bug, unless you know what you
+are doing.
+Description of Problem:
+The Mono runtime is not properly storing and retrieving state for shared
+resources where their state is kept in the scratch files in .wapi.  The
+iFolder team is having problems opening reading and closing files with the
+FileShare parameter in a File.Open call set to "None".  Multiple processes
+continually repeat this pattern and eventually every call to open will
+return a Sharing Violation exception even when nobody has the file open. 
+We can easily reproduce this problem by having n number of processes repeat
+the pattern described above and then start another process that does
+nothing more than new up a shared Mutex (new Mutex(false, "shared-name"))
+acquire the mutex and then block on a Console.ReadLine forever.
+Steps to reproduce the problem:
+1. We have included a test program that will reproduce the problem.
+2. Run two instances of the test program without any input arguments.
+3. Run another instance of the test program and pass in a "M" as the 
+only argument.
+Actual Results:
+Eventually the first two instances will seem like they're deadlocked but in
+fact they are just getting sharing exception every time they try and open
+the file
+Expected Results:
+The first two instances should run forever with the desired pattern of
+opening, reading and closing on every iteration.
+How often does this happen? 
+usually within 10 minutes of starting the three instances of the test program.
+Additional Information: