Call Stack window doesn't scroll to the active thread when a breakpoint is hit

[sean-mcmanus]

• VSCode Version: 1.31.0
• OS Version: Windows 10

Steps to Reproduce:

1. Use the C/C++ extension to debug our Microsoft.VSCode.CPP.Extension.exe.
2. Hit a breakpoint.

Bug: The call stack windows doesn't scroll to the thread that is active (paused on a breakpoint). Stepping causes some buggy scroll to occur, but it still doesn't scroll to the correct call stack. This makes it difficult to locate which thread call stack I'm currently debugging.

Does this issue occur when all extensions are disabled?: Yes, but needs the C/C++ extension to debug.

[vscodebot]

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• Call Stack "Paused On Breakpoint" UI not visible for long thread names (#68276)
• Call Stack appears broken (#67791)

[sean-mcmanus]

This is not a duplicate of the 2 issues mentioned by the bot.

[Jeff-Lewis]

I get the similar behavior debugging using PowerShell extension. I see the Hit Line breakpoint on... in the Terminal but VSCode does not select ANY line in the Call Stack when a breakpoint is hit. The Explorer sections 'Variables' and 'Watch' are empty, which make it look like it's not debugging, but it is. If I manually select a line in the Call Stack, then the explorer panes load with debug info.

This occurs for most but not every launch configuration. For simple PS Launch Current File... type launches it appears to automatically select the top of the stack when a breakpoint is hit. Others it does not select any line in the stack. I'll have to spend some time isolating a simple repeatable case, which I won't be able to get to for a while...

[weinand]

This issue is most likely a duplicate of #68616.

See my comment for an explanation what's happening.

In your screencast I see some deemphasized top frames which explain why you are running into this issue.

Do you have an option to turn "deemphasizing top frames" off?

/cc @isidorn

[vscodebot]

Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for existing issues here. See also our issue reporting guidelines.

Happy Coding!

[pieandcakes]

@weinand We don't do anything to signal that the frames are different. Is there something we should be sending in the protocol that we are not?

In Sean's original post those frames just have unknown source but i didn't think we were sending anything special for it.

[pieandcakes]

Also based on this comment should the pointer be on the first available frame in the stack with it marked in green?

[weinand]

The first three frames are dimmed because they have no source. So it's probably not the DA that sends frames with the deemphasized hint.

@pieandcakes No, no you don't need to send anything special here.

Yes, if the first frame with source available is not the top frame, the pointer and the highlight should be green.

@isidorn when fixing #68616 please make sure that this works correctly.

[sean-mcmanus]

@isidorn If this fix goes into Insiders, I can test our C++ scenario for you if you want.

[isidorn]

@sean-mcmanus can you please verify this works correctly with latest vscode insiders?
Thank you

[sean-mcmanus]

@isidorn The call stack is broken. It randomly won't scroll to the correct call stack, even when stepping or hitting breakpoints. For many cases it fails 100% of the time. Stepping is the main random case (50% failure?). I'm not able to observe any fixed behavior. I'm using:

Version: 1.32.0-insider (user setup)
Commit: 393b48d
Date: 2019-02-25T01:34:48.785Z
Electron: 3.1.3
Chrome: 66.0.3359.181
Node.js: 10.2.0
V8: 6.6.346.32
OS: Windows_NT x64 10.0.17763

[isidorn]

Thanks for letting us know. For this we would aslo need the revealTo API which is probably coming for #68627
Reopening

[isidorn]

@sean-mcmanus I can not reproduce this using the example in #68648
This feels like the same issue as #68627
When you say the call stack is broken you actually mean that the correct stack frame does not get revelead? Or it aslo does not get focussed? Or how exactly broken do you mean?

When this happens do you see some errors in F1 > developer tools > console

[sean-mcmanus]

@isidorn Yeah, it could be #68627. By broken I mean the call stack that hit the "Paused on Breakpoint" is not scrolled to and it's not highlighted, making it hard to locate when there are 20+ threads. I'll send you an email with more screenshots.

There are no errors in the console.

[isidorn]

It is alwas great when we have all the data in the issue, so no need for seperate emails.
Since I can not reproduce can you F1 > developer tools > put a breakpoint here and investigate what is going on.
Also note that we are looking into #68648 and #68627 so once of those might fix this. In the meantime moving this one to march.

[sean-mcmanus]

I got a repro and debugged it -- the updateSelectionAndReveal gets hit and the [element] is the correct call stack frame, but for some unknown reason the scroll and highlight fails. I got the exception "Errror: Data tree not not found: Microsoft.VSCode.CPP.Extension.exe!gcc_info::get_system_defaults..." with node "undefined", but I get those exceptions a lot so it could be "by design"? I'm not sure what else to look for when debugging. The repro probability seems higher the 1st time I debug and hit a breakpoint than with later calls.

Screenshot before updateSelectionAndReveal:

Screenshot after updateSelectionAndReveal (no scrolling occurred):

Also, here's a screenshot of the exception message when I got a different repro and then enabled Pause on Exceptions:

I could wait for those other issues to be fixed.

[isidorn]

@sean-mcmanus thanks for looking into this.
I think this will not get fixed by the other issues.
I plan to investigate this more next week. For than can you please give me a step by step repro so I look on my machine? Please note that I do not know C++, so providing a full simple reproducable repository would be great.

[vscodebot]

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.

Happy Coding!

[lieff]

I have same issue on Linux.

[isidorn]

@joaomoreno here's another case of data tree node not found. Where I try to reveal something which is not known to the tree.
Smeels like a duplicate of #69950

So I suggest that we first fix that and then double check if this got fixed

[isidorn]

@sean-mcmanus this should be fixed now. Can you please try it starting from Friday's vscode insiders. If you still see it let us know and we will reopen.

[alexr00]

Verified because the probably duplicate is verified?

[isidorn]

Yeah duplicate, removing bug label