Search Issue Tracker
Fixed in 5.5.0
Votes
0
Found in
Issue ID
772064
Regression
No
System.Threading.Monitor.Wait() prematurely aborted when debugger is attached
Description / Repro Steps:
UnityVS debugger is causing threads that are suspended via calls to System.Threading.Monitor.Wait() to be woken back up again. This in turn wreaks havoc on low level synchronization primitives such as ManualResetEventSlim.
Version 5.4.0b7 (435d6f5b598c)
Windows 10 | OS x64 | 16 GB RAM | Intel Proc i7
Repro Steps:
1. Open a new Unity Project
2. Create a new GameObject
3. Attach the script provided
4. Observe - If you hit play without a debugger attached, it works as expected and the Monitor.Wait call blocks the thread for 2 seconds and then returns true.
5. Observe - If I hit play with a UnityVS debugger attached, the Wait() operation immediately returns false.
Expected:
Attaching a debugger doesn’t cause suspended threads to awake
Actual:
Suspended threads are being woken back up with a UnityVS debugger attached
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Redoing creation of Sub Scenes and Cube GameObjects in Hierarchy throws “Assertion failed on expression: 'targetScene != nullptr’” error in Console window
- Selecting “New Sub Scene” after assigning “New Scene” in Sub Scene Script Component throws “Destroying GameObjects immediately is not permitted” in the Console window
- Shader Graph "Zoom Step Size" can be set to 0 even though the zoom still works
- Enabling/Disabling the Deprecated Nodes doesn't apply to the opened Shader Graph unless any Variable is added to the Blackboard
- Group Selection title text size is smaller in renaming than the actual font size
Add comment