Search Issue Tracker
Fixed in 5.5.0
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
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.
Attaching a debugger doesn’t cause suspended threads to awake
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.
- Semi transparent particles are incorrect in the game view
- [iOS] UI elements are invisible on iOS devices when using AdditionalUIRenderer
- Setting ArticulationBody.collisionDetectionMode at runtime via script to Discrete does not work if its being set from Continuous
- [iOS] Crash on ScriptingGCHandle::Acquire when calling RequestUserAuthorization without using yield for pending authorization
- Particle is not visible in RenderTexture when Renderer's material is set to Default-Particle and Camera's BG Alpha is set 0