Search Issue Tracker
By Design
Votes
0
Found in [Package]
2.0.12
Issue ID
VS-45
Regression
No
Framerate drops when attaching VS2019 or VS2022 debugger
How to reproduce:
1. Open the user's attached "sdna.zip" folder
2. Open the "Unity" project
3. Open the "GeneratedMap" Scene
4. Go to Assets -> iop and open any C# file
5. Enter the Play mode in the editor
6. Move a character by left-clicking on the landscape
7. In Visual Studio editor press the "Attach to Unity" button
8. Focus on Unity editor
9. Observe the Game view
Expected result: The game doesn't freeze
Actual result: The game freezes
Reproducible with: 2.0.11, 20.0.12 (2020.3.18f1, 2021.1.20f1, 2021.2.0b11, 2022.1.0a9)
Couldn't test with: 2.0.11, 20.0.12 (2019.4.30f1) (Compilation error after downgrade)
Notes:
- Project loads correctly only on Windows 10
- Reproducible with VS 2019 and VS 2022
- When attaching Rider for the first time after 45 seconds game freezes for 10 seconds and then the "NullReferenceException" error message appears
- When attaching Unity with VS 2017 game freezes every 5 seconds for a few seconds
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Crash on ResizeScriptingList<ScriptingObjectPtr> when passing an undeclared variable to the results parameter for GameObject.FindGameObjectsWithTag
- [Android] "Screen.safeArea.y" always returns values outside of the Safe Area when the device is in Portrait orientation
- Frame spike due to many TreeRenderer.TreeUpdated calls when repositioning terrains in large Scenes
- Crash on GameObject::RemoveComponentFromGameObjectInternal when reparenting Text GameObjects
- [IL2CPP-GarbageCollector] Changing GCMode might permanently disable GC in a multithreaded context
Resolution Note:
Message from Microsoft:
We added an optimization on our side, but in this case I really think it's a user code issue. Our advice is to make sure Exception support is enabled (see above), open Exception Settings and create an UnityEngine.UnityException under Common Language Runtime Exception group. Then it's easy to find the culprit: a call to Destroy outside the main thread, Line 319 in HUDUnity.cs. Commenting this line is insta-fixing the issue. It is hard to track because Unity is not displaying an error message, probably because we are in a finalizer.