[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.
http://bugzilla.ximian.com/show_bug.cgi?id=61644
--- 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:
+OS Details: Novell Linux Desktop Beta 1
+Status: NEW
+Resolution:
+Severity: 001 One hour
+Priority: Blocker
+Component: misc
+AssignedTo: mono-bugs@ximian.com
+ReportedBy: banderso@novell.com
+QAContact: mono-bugs@ximian.com
+TargetMilestone: ---
+URL:
+Cc:
+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: