Search Issue Tracker
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
- 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
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
- Input Field ignores first keyboard input when calling Focus() from code
- GC Alloc when using Graphics.RenderMeshInstanced
- [VFX Graph][URP] VFX crashes on URP when dragging VFX asset to the Hierarchy window
- InvalidOperationException when using AsyncGPUReadback.RequestIntoNativeArray
- Generated Entities look different when Depth Priming Mode is changed
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! :)