Potential breakpoint locations shown on every line in file

[mjbvz]

Issue Type: Bug

Repo
Not sure of exact repo steps. Here's how I can reproduce the bug:

1. Start an oss build of VS Code
2. From insiders, attach to extension host and start debugging one of our built-in extensions
3. Hit a breakpoint in the extension.
4. Now delete some lines in the file (possible the one where the breakpoint was)
5. Detach and reattach the debugger

Bug
Potential break point locations are show on every line of the file

VS Code version: Code - Insiders 1.39.0-insider (c8252b6, 2019-10-04T09:23:20.797Z)
OS version: Darwin x64 18.7.0

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz (8 x 2200)
GPU Status	2d_canvas: enabled flash_3d: enabled flash_stage3d: enabled flash_stage3d_baseline: enabled gpu_compositing: enabled multiple_raster_threads: enabled_on native_gpu_memory_buffers: enabled oop_rasterization: disabled_off protected_video_decode: unavailable_off rasterization: enabled skia_deferred_display_list: disabled_off skia_renderer: disabled_off surface_synchronization: enabled_on video_decode: enabled viz_display_compositor: disabled_off webgl: enabled webgl2: enabled
Load (avg)	2, 3, 2
Memory (System)	16.00GB (0.14GB free)
Process Argv	-psn_0_3486547
Screen Reader	no
VM	18%

[isidorn]

I can not reproduce this following your exact steps.
Though I see that on line deletion there are some left-over candidate locations. Though I can not get in the "extreme" case that you got here.
imho this is a corner case which we should fix on insiders not as a candidate

[isidorn]

Chrome simply does not show any candidates if the file gets changes. We can do something similar.
Also after discussing in standup we decided this is fine for October
@mattbierner let me know if you always ee this and if yes can you give more precise steps so we can consider this for september

[Clancey]

This started happening to me after upgrading to Catalina. It happens on both 1.39 and the 1.40 releases

Commit: 88f15d17dca836346e787762685a40bb5cce75a8
Date: 2019-10-10T23:35:11.314Z
Electron: 4.2.10
Chrome: 69.0.3497.128
Node.js: 10.11.0
V8: 6.9.427.31-electron.0
OS: Darwin x64 19.0.0```

[Clancey]

When I set breakpoints without debugging enabled they set properly. When I start debugging no break points work until I reset them. When I set them a second time I get the behavior listed in this bug report. In my debug output, I see:

    at Timeout.setTimeout [as _onTimeout] (/Applications/Visual Studio Code.app/Contents/Resources/app/extensions/ms-vscode.node-debug2/node_modules/vscode-chrome-debug-core/out/src/utils.js:96:24)
    at ontimeout (timers.js:425:11)
    at tryOnTimeout (timers.js:289:5)
    at listOnTimeout (timers.js:252:5)
    at Timer.processTimers (timers.js:212:10)
Error: Set breakpoints request timed out
    at Timeout.setTimeout [as _onTimeout] (/Applications/Visual Studio Code.app/Contents/Resources/app/extensions/ms-vscode.node-debug2/node_modules/vscode-chrome-debug-core/out/src/utils.js:96:24)
    at ontimeout (timers.js:425:11)
    at tryOnTimeout (timers.js:289:5)
    at listOnTimeout (timers.js:252:5)
    at Timer.processTimers (timers.js:212:10)```

[isidorn]

@Clancey can you provide exact repo steps, with a potential repository?
@mjbvz more precise repro steps from you would also be appreciated. Thanks

[Clancey]

It's not a public repo, however I think I narrowed it down. It has to do with WebPack.

[isidorn]

If it is webpack related than it seems that the node debugger is returning strange candidates for a line. Thus also assigning to @roblourens

[roblourens]

I think this stuff falls under microsoft/vscode-chrome-debug-core#531 (the DA should be sure to only return breakpointLocations for the line that was requested) so I will close it as a dupe