Search Issue Tracker
By Design
Votes
0
Found in
2019.4
2020.2.1f1
2020.3
2021.3
2022.1
2022.2
Issue ID
1308839
Regression
No
Double-clicking on "Debug.Log()" message doesn't open the script when Log Stack Trace is set to "Full"
How to reproduce:
1. Open the attached "1308839_Repro.zip" project
2. Open the Scene "SampleScene"
3. Open the Player Settings (Edit->Player Settings...)
4. Make sure in the Other Settings tab under "Stack Trace" Log option is set to "Full"
5. Enter the Play Mode
6. In the Console double-click on the "Hello" message
Expected results: The script is open
Actual results: Nothing happens
Reproducible with: 2019.4.39f1, 2020.3.35f1, 2021.3.f1, 2022.1.2f1, 2022.2.0a15
Notes:
- Installing the Packages on a 3D Template does not reproduce the issue
- The Debug.Log message provides this stacktrace along the log:
0x00007ff7336c8c8c (Unity) StackWalker::GetCurrentCallstack
0x00007ff7336d1069 (Unity) StackWalker::ShowCallstack
0x00007ff734ba564c (Unity) GetStacktrace
0x00007ff735c64803 (Unity) DebugStringToFile
0x00007ff73385c439 (Unity) DebugLogHandler_CUSTOM_Internal_Log
- Upgrading/downgrading the packages that come with Mobile 3D does not produce/fix the issue
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
- Articulation Body with 'Revolute' Joint Type has erratic behavior when Upper Limit is set to above 360
- WebGL Player fails to render Scene when Terrain with Detail Mesh is added and WebGPU Graphics API is used
- Inconsistent errors are logged when different types are passed into the Query "Q<>" method in UIToolkit and the ancestor VisualElement is null
- Crash on GetMaterialPropertyByIndex when opening a specific Scene
- Discrepancies in the styling are present when using a TSS file instead of a USS file in custom EditorWindow
Resolution Note (2022.2.X):
Hi, thanks for reporting this issue.
The issue that seems to happen here is that stacktraces are set to "Full". If set to "Script Only", it should always work - double clicking on the message and the IDE will open the correct place.
Another issue might be that if you use Visual Studio, compared to other IDE's, it will reopen the solution file in the last state it was used, in cases where the filename and line are not extracted from the stacktrace ("None" and "Full). This added to the confusion when we initially started to investigate as well.
Those things being said, we added an internal task to revisit this behavior, and extract the needed information from the message when StackTraces are set to "Full", in order for it to open the correct place this is happening, which again, historically wasn't the case. Hope that makes sense! :)