System.Threading.Tests.MutexTests tests failing on Linux #28449
Labels
area-System.Threading
disabled-test
The test is disabled in source code against the issue
test-bug
Problem in test source code (most likely)
Milestone
Comments
|
cc @stephentoub |
|
maryamariyan
added
the
untriaged
stephentoub
removed
the
untriaged
kouvel
added a commit
to kouvel/runtime
that referenced
this issue
May 12, 2020
Below when I refer to "mutex" I'm referring to the underlying mutex object, not an instance of the `Mutex` class.
- When the last reference to a mutex is closed while the lock is held by some thread and a pthread mutex is used, the mutex was attempted to be destroyed but that has undefined behavior
- There doesn't seem to be a way to behave exactly like on Windows for this corner case, where the mutex is destroyed when the last reference to it is released, regardless of which process has the mutex locked and which process releases the last reference to it (they could be two different processes), including in cases of abrupt shutdown
- For this corner case I settled on what seems like a decent solution and compatible with older runtimes:
- When a process releases its last reference to the mutex
- If that mutex is locked by the same thread, the lock is abandoned and the process no longer references the mutex
- If that mutex is locked by a different thread, the lifetime of the mutex is extended with an implicit ref. The implicit ref prevents this or other processes from attempting to destroy the mutex while it is locked. The implicit ref is removed in either of these cases:
- The mutex gets another reference from within the same process
- The thread that owns the lock exits and abandons the mutex, at which point that would be the last reference to the mutex and the process would not reference the mutex anymore
- The implementation based on file locks is less restricted, but for consistency that implementation also follows the same behavior
- There was also a race between an exiting thread abandoning one of its locked named mutexes and another thread releasing the last reference to it, fixed by using the creation/deletion process lock to synchronize
Fix for dotnet#34271 in master
Closes dotnet#28449 - probably doesn't fix the issue, but trying to enable it to see if it continues to fail
kouvel
added a commit
that referenced
this issue
May 13, 2020
Fix Unix named mutex crash during some race conditions
Below when I refer to "mutex" I'm referring to the underlying mutex object, not an instance of the `Mutex` class.
- When the last reference to a mutex is closed while the lock is held by some thread and a pthread mutex is used, the mutex was attempted to be destroyed but that has undefined behavior
- There doesn't seem to be a way to behave exactly like on Windows for this corner case, where the mutex is destroyed when the last reference to it is released, regardless of which process has the mutex locked and which process releases the last reference to it (they could be two different processes), including in cases of abrupt shutdown
- For this corner case I settled on what seems like a decent solution and compatible with older runtimes:
- When a process releases its last reference to the mutex
- If that mutex is locked by the same thread, the lock is abandoned and the process no longer references the mutex
- If that mutex is locked by a different thread, the lifetime of the mutex is extended with an implicit ref. The implicit ref prevents this or other processes from attempting to destroy the mutex while it is locked. The implicit ref is removed in either of these cases:
- The mutex gets another reference from within the same process
- The thread that owns the lock exits and abandons the mutex, at which point that would be the last reference to the mutex and the process would not reference the mutex anymore
- The implementation based on file locks is less restricted, but for consistency that implementation also follows the same behavior
- There was also a race between an exiting thread abandoning one of its locked named mutexes and another thread releasing the last reference to it, fixed by using the creation/deletion process lock to synchronize
Fix for #34271 in master
Closes #28449 - probably doesn't fix the issue, but trying to enable it to see if it continues to fail
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
From dotnet/corefx#34500
Debian.8.Amd64.Open-x64-Release
https://mc.dot.net/#/user/tkp1n/pr~2Fjenkins~2Fdotnet~2Fcorefx~2Fmaster~2F/test~2Ffunctional~2Fcli~2F/ecffe5046608086201c8716ae132ddacbd7182d8/workItem/System.Threading.Tests/analysis/xunit/System.Threading.Tests.MutexTests~2FCrossProcess_NamedMutex_ProtectedFileAccessAtomic(prefix:%20%5C%225e65042415ce448f872dae5fb40e7a74%5C%22)
System.Threading.Tests.MutexTests/CrossProcess_NamedMutex_ProtectedFileAccessAtomic(prefix: "5e65042415ce448f872dae5fb40e7a74")
Debian.8.Amd64.Open-x64-Release
https://mc.dot.net/#/user/tkp1n/pr~2Fjenkins~2Fdotnet~2Fcorefx~2Fmaster~2F/test~2Ffunctional~2Fcli~2F/ecffe5046608086201c8716ae132ddacbd7182d8/workItem/System.Threading.Tests/analysis/xunit/System.Threading.Tests.MutexTests~2FCrossProcess_NamedMutex_ProtectedFileAccessAtomic(prefix:%20%5C%22Local%5C%5C%5C%5C65f91a48792b41ba9b7e699108f7de52%5C%22)
System.Threading.Tests.MutexTests/CrossProcess_NamedMutex_ProtectedFileAccessAtomic(prefix: "Local\\65f91a48792b41ba9b7e699108f7de52")
cc @kouvel
The text was updated successfully, but these errors were encountered: