VS Code freezes when showing a disassembly view if the top stack frame's instruction pointer points between disassembled instructions #147163
Description
Issue Type: Bug
Steps to reproduce:
- Clone https://github.com/Microsoft/vscode-mock-debug.git at 196fef7b1235602aeff47145279b2c0f322aa242.
- Apply the attached patch (it's a simple one-liner that reports only every second instruction in the disassembly response). disassembly-fail.patch.txt
- Run the extension host.
- Set up a breakpoint at line 55 of readme.md (the one that starts with "If a markdown line contains the word 'disassembly'").
- Start the mock debugger.
- Continue until it hits the breakpoint.
- Right-click the top stack frame, select "Open Disassembly View". You should see the disassembly view with the current instruction pointing at 0x1e2.
- Click the "Step over" button.
- Click Step Over.
Expected result: ideally, VS Code should notice that the disassembly doesn't reflect the reality and request disassembly originating in the place pointed to by the current instruction pointer.
Actual result: VS Code freezes completely, the Code Helper (Renderer) process occupies 100% CPU. The only way to regain control is to kill it.
Explanation of what happens: the patch arbitrarily forces the debug adapter to only report every second instruction to VS Code, thus creating a more realistic disassembly situation, where instructions span more than just one byte. Since the debugger adapter still steps through just one address, it simulates a situation where the instruction pointer ends up on an address that is not a valid start of instructions (at least according to the current disassembly). This might happen due to many different conditions: perhaps misinterpretation of a data segment, perhaps a broken interrupt vector, perhaps memory corruption.
Let me just argue why this is important: although I'm just creating a toy project here (a 6502 emulator that I decided to hook to an existing debugger UI), I think that this case may render the VS Code disassembler useless when dealing with things like self-modifying code, debugging binaries without source code (in which case disassembly is a heuristic process that only works well if the code and are strictly separated), JIT compilers, etc. I think that VS Code should do the following, in the order of importance:
- Detect that "something is wrong" and refresh the disassembly view if a matching line can't be found in the disassembly.
- Even if the disassembler is "stubborn", and doesn't return a disassembly that would be valid from the perspective of the current instruction pointer, VS Code should at least not freeze.
- Support memory events and allow them to invalidate a region of disassembly.
VS Code version: Code 1.66.1 (8dfae7a, 2022-04-06T14:49:47.400Z)
OS version: Darwin x64 19.6.0
Restricted Mode: No
System Info
| Item | Value |
|---|---|
| CPUs | Intel(R) Core(TM) i7-8557U CPU @ 1.70GHz (8 x 1700) |
| GPU Status | 2d_canvas: enabled canvas_oop_rasterization: disabled_off direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled metal: disabled_off multiple_raster_threads: enabled_on oop_rasterization: enabled opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok skia_renderer: enabled_on video_decode: enabled video_encode: enabled webgl: enabled webgl2: enabled |
| Load (avg) | 3, 3, 3 |
| Memory (System) | 16.00GB (5.05GB free) |
| Process Argv | . --crash-reporter-id 0d143bc3-9c4f-4fa6-9de4-297abe9fb736 |
| Screen Reader | no |
| VM | 0% |
A/B Experiments
vsliv368:30146709
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
vstes627:30244334
pythonvspyl392:30443607
pythontb:30283811
pythonvspyt551:30345470
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
vscorecescf:30445987
pythondataviewer:30285071
vscod805:30301674
pythonvspyt200:30340761
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
vsaa593cf:30376535
vsc1dst:30438360
pythonvs932:30410667
wslgetstarted:30449410
pythonvsnew555:30457759
vscscmwlcmt:30465135
cppdebug:30466689
pynewfile477:30463512