search

dotnet / vscode-csharp

Official C# support for Visual Studio Code
MIT License
2.86k stars 671 forks source link

Debugger: Call stack sometimes wrong after 'Pause' on Linux #1616

Open GraceDong opened 7 years ago

GraceDong commented 7 years ago

Environment data

dotnet --info output:

VS Code version: v1.13.1 C# Extension version: v1.12.0-beat1

Steps to reproduce

  1. Open attached folder. hwapp.zip

  2. Select '.NET Core Attach'.

  3. Run 'dotnet run' command in termnal.

  4. Press F5 to select process and start debugging.

  5. Press 'Pause'

Expected behavior

The cursor should be hit the current line contains text 'Thread.Sleep(1000);' and Call Stack window should be as following: image

Actual behavior

The cursor didn't hit any line and the Call Stack frame is incorrectly: image

log.txt

GraceDong commented 7 years ago

This issue can reproduce in launch a web application. Repro Steps:

  1. Create a MVC application using command;
  2. Open the application with VSCode;
  3. F5;
  4. Pause;

Expected: The cursor should be hit the current line contains text 'host.Run();'. Actual: The cursor didn't hit any line.

gregg-miskelly commented 7 years ago

Grace's issue is that the debugger isn't able to walk the call stack on the thread with the user code, hence it doesn't think there is any user code on the thread, and hence it will not select that thread.

<- (R) {"seq":46,"type":"response","request_seq":11,"success":true,"command":"stackTrace","message":"","body":{"stackFrames":[{"id":1000,"name":"[External Code]","line":0,"column":0}],"totalFrames":3}}
<- (R) {"seq":47,"type":"response","request_seq":12,"success":true,"command":"stackTrace","message":"","body":{"stackFrames":[],"totalFrames":0}}
<- (R) {"seq":48,"type":"response","request_seq":13,"success":true,"command":"stackTrace","message":"","body":{"stackFrames":[],"totalFrames":0}}
gregg-miskelly commented 7 years ago

I was able to reproduce the problem. For me at least, it isn't a 100% repro - sometimes we get correct call stacks and sometimes we don't. At least so far, it seems like it is some property of the target process as to if it will give me good stacks as pretty F5 and then pause again, or detaching and reattaching produces the same results.