[Mono-bugs] [Bug 61644][Blo] New - Mixed up state using shared resources in Mono
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 email@example.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 @@
+Product: Mono: Runtime
+OS Details: Novell Linux Desktop Beta 1
+Severity: 001 One hour
+Summary: Mixed up state using shared resources in Mono
+Please fill in this template when reporting a bug, unless you know what you
+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
+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 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.