search

microsoft / vscode

Visual Studio Code
https://code.visualstudio.com
MIT License
162.93k stars 28.77k forks source link

Call Stack bounces when short-lived second requests start/stop #122775

Open dariusj18 opened 3 years ago

dariusj18 commented 3 years ago

Issue Type: Bug

When using the PHP debugger I have a request paused and awaiting, however while that request is running other requests are also running but not pausing, as expected. The problem is that while there is only one request in the call stack, the call stack for the paused request is expanded, however when a second request is running the paused call stack gets collapsed and it shows two requests, with the paused request having an expansion arrow. Then the second request ends and the call stack again shows the full single request's call stack. Because of the nature of the application and my local dev environment, this is constantly happening, and focusing on anything or expanding it doesn't prevent me form losing my place.

VS Code version: Code 1.55.2 (3c4e3df9e89829dce27b7b5c24508306b151f30d, 2021-04-13T09:35:57.887Z) OS version: Windows_NT x64 10.0.19041

System Info |Item|Value| |---|---| |CPUs|Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz (8 x 2592)| |GPU Status|2d_canvas: enabled
gpu_compositing: enabled
multiple_raster_threads: enabled_on
oop_rasterization: enabled
opengl: enabled_on
protected_video_decode: unavailable_off
rasterization: enabled
skia_renderer: enabled_on
video_decode: enabled
vulkan: disabled_off
webgl: enabled
webgl2: enabled| |Load (avg)|undefined| |Memory (System)|15.96GB (3.41GB free)| |Process Argv|--crash-reporter-id 7d9cd352-3b0d-45b8-a763-88770b5a2e02| |Screen Reader|no| |VM|0%|
Extensions (47) Extension|Author (truncated)|Version ---|---|--- vscode-base64|ada|0.1.0 Bookmarks|ale|13.0.4 project-manager|ale|12.1.0 vscode-intelephense-client|bme|1.7.0 npm-intellisense|chr|1.3.1 bracket-pair-colorizer|Coe|1.0.61 dakara-foldplus|dak|1.5.1 hex-to-rgba|dak|1.0.0 php-class-generator-composer-psr-4|dam|1.0.1 vscode-eslint|dba|2.1.20 gitlens|eam|11.4.1 EditorConfig|Edi|0.16.4 vscode-npm-script|eg2|0.3.21 phpunit|ema|4.1.1 prettier-vscode|esb|6.3.2 php-debug|fel|1.14.12 auto-close-tag|for|0.5.10 php-awesome-snippets|hak|1.1.3 composer|ika|0.7.1 phpcs|ika|1.0.5 code-select-until|jak|0.6.0 vue|jcb|0.1.5 vscode-cfml|Kam|0.5.3 string-manipulation|mar|0.5.2 rainbow-csv|mec|1.8.1 vscode-language-babel|mgm|0.0.31 git-graph|mhu|1.30.0 dotenv|mik|1.0.1 laravel-intellisense|moh|0.2.0 vscode-apache|mrm|1.2.0 remote-wsl|ms-|0.54.6 php-docblocker|nei|2.1.0 indent-rainbow|ode|7.5.0 react-proptypes-intellisense|OfH|1.0.3 laravel-blade|one|1.25.0 vscode-versionlens|pfl|1.0.9 vscode-php-getters-setters|php|1.2.3 vscode-yaml|red|0.18.0 laravel-artisan|rya|0.0.27 uridecode|sry|0.3.5 addDocComments|ste|0.0.8 code-spell-checker|str|1.10.2 vscode-input-sequence|tom|0.2.0 lorem-ipsum|Tyr|1.2.0 vscode-w3cvalidation|Umo|2.9.1 vscode-icons|vsc|11.4.0 vscode-proto3|zxh|0.5.3
A/B Experiments ``` vsliv368:30146709 vsreu685:30147344 python383:30185418 pythonvspyt602cf:30294773 vspor879:30202332 vspor708:30202333 vspor363:30204092 vstry914:30276682 pythonvspyt639:30291489 pythontb:30283811 vspre833cf:30267465 pythonptprofiler:30281270 vsdfh931cf:30280410 vscnewfilehidden:30294815 vshan820:30294714 vscoreces:30290705 pythondataviewer:30285071 vscus158:30286553 vscgsv2:30294352 ```
isidorn commented 3 years ago

Please file this against the php debug extension that you are using. This does not happen with other debug extensions. If you think this is a vscode issue please fork https://github.com/microsoft/vscode-mock-debug and create a reproducable issue. Thanks

dariusj18 commented 3 years ago

I see a similar situation with the mock debugger, when a new debugging request has started the currently focused stack thread loses focus and the new break point it automatically focused. Even when the new request has continued, the focus never goes back, nor is there a way to know readily where the focus was. Additionally when the first request was in the stack trace, it did not act as a collapsible entity, however after the second request was added, the stack trace window was rearranged so that each request was collapsible, though after the second request was completed the first request did maintain it's status as a collapsible entity.

Given the nature of the mock debugger I am not sure if this is caused by the fact that you have to execute a new request manually. I chose to add a new test2.md file and a new launch.json entry to simulate.

dariusj18 commented 3 years ago

Also from what I can tell this is definitely VSCode that tries to show the stack traces in a different format if there is one of them vs. if there are multiple. Screen shots are attached to this issue: https://github.com/xdebug/vscode-php-debug/issues/558#issuecomment-831477710

isidorn commented 3 years ago

If you can repro with mock debug can you write concise exact steps so I can repro on my machine as well. Thanks

dariusj18 commented 3 years ago
  1. Run the extension
  2. Set a breakpoint in test.md (not sure if this is required)
  3. Start Debugging "Debug test.md"
  4. While debugging session is still paused, Start Debugging "Debug test.md" again. The first debugging session becomes a collapsed section.
  5. Continue the debugging session "Debug test.md 2" The first debugging session remains as a collapsed section, which is better than what is happening with the PHP Debug extensions, where it changes back into a single thread not under a collapsible section.

image image image

isidorn commented 3 years ago

So the gist is: "the session gets auto collapsed when a new session pauses on a breakpoint". Right?

dariusj18 commented 3 years ago

Sort of, the session originally isn't in a collapsible section and when another request is shown on the call stack (whether is it a paused or just showing as running) it transforms into a collapsed section. Then when the other session is no longer there it becomes a non collapsible list again, losing ones place.

isidorn commented 3 years ago

Ok, let me reopen and I can investigate more in the future

weinand commented 3 years ago

I agree, we should not collapse a paused session when a new session arrives.

rzhao271 commented 3 years ago

I still hit https://github.com/microsoft/vscode/issues/122775#issuecomment-833561587 using Mock Debug

isidorn commented 3 years ago

That is expected. When there is only one session we do not show it in the call stack view (to simplify). Thus in that case it is not collapsable. What I fixed here is "We should not collapse a paused session when a new session arrives."

No further changes planned here, as we did not receive any other negative feedback regarding this behaviour

dariusj18 commented 3 years ago

This doesn't seem to have been fixed. The call stack still collapses when a new one is added @rzhao271 is right and the issue isn't resolved. If you happened to have fixed some other issue as a result, happy accident, however the behavior described above still persists.

isidorn commented 3 years ago

Ok, let's reopen. I will follow steps from https://github.com/microsoft/vscode/issues/122775#issuecomment-832696897

isidorn commented 2 years ago

Somehow forgot to forward this to @roblourens when he took over Debug. I am not sure if this still repros after Rob's change regarding firing events after fetching call stack parts.

roblourens commented 1 year ago

This still reproes

roblourens commented 1 year ago

Notes- we have this code that autoexpands sessions: https://github.com/microsoft/vscode/blob/d4cd8bb458a040330fbff18d7c77087479102141/src/vs/workbench/contrib/debug/browser/callStackView.ts#L196. Should we autoexpand a thread/session whenever it pauses? I'm actually not sure, it can be noisy and also lead to losing your place.

What I see is slightly different than the screenshots above, which is that the first session remains expanded, but the new one is collapsed, so your focus can stay on the current one. This seems not that bad to me.