search

dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
15.26k stars 4.73k forks source link

Blazor WASM "Debug Adapter" fail to handle breakpoints when a Web Worker is present #98208

Open mattincode opened 9 months ago

mattincode commented 9 months ago

Is there an existing issue for this?

Describe the bug

When a Web worker is created in a Blazor WebAssembly project the debugger(Visual Studio 2022) will stop working since the "Debug Proxy" seems to disconnect. Once the web worker is active unset/set breakpoints in Visual Studio 2022 will display Unable to retrieve source content. example project: BlazorWasmDebugBrokenWithWebWorker

Expected Behavior

The breakpoint in Visual Studio 2022 should be set without any error message.

Steps To Reproduce

How to reproduce

  1. Run the example project in the VS2022 debugger.
  2. Open the "Counter"-page <- This will create a web worker
  3. Set a breakpoint in the "IncrementCount" method
  4. Click the "Click me" button.
  5. The breakpoint will be hit -> Press "continue" in the VS2022 debugger.
  6. Uncheck the breakpoint and then set it again on the same line.

Result

The debugger will stop in javascript and display Unable to retrieve source content

Expected result

The breakpoint should be set without any error message.

Exceptions (if any)

No response

.NET Version

8.0.101

Anything else?

No response

ghost commented 9 months ago

Tagging subscribers to this area: @thaystg See info in area-owners.md if you want to be subscribed.

Issue Details
### Is there an existing issue for this? - [X] I have searched the existing issues ### Describe the bug When a Web worker is created in a Blazor WebAssembly project the debugger(Visual Studio 2022) will stop working since the "Debug Proxy" seems to disconnect. Once the web worker is active unset/set breakpoints in Visual Studio 2022 will display `Unable to retrieve source content`. example project: [BlazorWasmDebugBrokenWithWebWorker](https://github.com/mattincode/BlazorWasmDebugBrokenWithWebWorker) ### Expected Behavior The breakpoint in Visual Studio 2022 should be set without any error message. ### Steps To Reproduce # How to reproduce 1. Run the [example project](https://github.com/mattincode/BlazorWasmDebugBrokenWithWebWorker) in the VS2022 debugger. 2. Open the "Counter"-page <- This will create a web worker 3. Set a breakpoint in the "IncrementCount" method 4. Click the "Click me" button. 5. The breakpoint will be hit -> Press "continue" in the VS2022 debugger. 6. Uncheck the breakpoint and then set it again on the same line. ## Result The debugger will stop in javascript and display Unable to retrieve source content ## Expected result The breakpoint should be set without any error message. ### Exceptions (if any) _No response_ ### .NET Version 8.0.101 ### Anything else? _No response_
Author: mattincode
Assignees: -
Labels: `area-Debugger-mono`
Milestone: -
mattincode commented 8 months ago

@tommcdon What is the reasoning behind setting issue #97987 as related? There is no information in that issue to indicate any Web Worker beeing present. Also, in that issue it "magically" resolved itself as is not the case with a Web Worker that will break the debugger 100% of the time. Since Microsoft has pushed multithreading for Blazor into the future the only way to do any form of background work is to use Web Workers. Since Web Workers break debug this issue is currently a big hurdle doing any effective development. Any timeline for when this issue can at least hit a triage process?

tommcdon commented 8 months ago

@tommcdon What is the reasoning behind setting issue #97987 as related? ...

Hello @mattincode! My statement in https://github.com/dotnet/runtime/issues/97987#issuecomment-1937870756 caused GH to "link" the issue. My statement suggests that there may be a relation between the two, but without a concrete details understanding the technical reason for the failure, we don't know what the root cause is yet.

Any timeline for when this issue can at least hit a triage process?

My apologize for the delay in investigation. Our team is actively investigating top customer issues and we have already put this issue on to our backlog for further investigation.

michelkommers commented 3 weeks ago

There is a workaround for this? Or only wait for a fix? The issue is still present in latest releases