Attach-to-PID incorrectly defaults to unsupported "subProcess":true

[amine-aboufirass]

Type: Bug

• VS Code Version:

1.77.1
b7886d7461186a5eac768481578c1d7ca80e2d21
x64

• OS Version:
  

Steps to Reproduce:

Folder contents:

.vscode
    launch.json
cli.py
test_debugpy_issue_simplified.py

Contents of cli.py:

print("hello world")

Contents of test_debugpy_issue_simplified:

import subprocess
import os
import json

print(os.getpid())
input()

configArgs = ["python", "cli.py"]

ret_code=0
while ret_code==0:
    ret_code = subprocess.call(configArgs, shell=False, universal_newlines=True)
    print(ret_code)

Contents of launch.json:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Python: Current File",
            "type": "python",
            "request": "launch",
            "program": "${file}",
            "console": "integratedTerminal",
            "justMyCode": true
        },
        {
            "name": "Python: Attach using Process Id",
            "type": "python",
            "request": "attach",
            "processId": "${command:pickProcess}",
            "justMyCode": true
        }
    ]
}

In order to replicate the issue, carry out the following steps:

• Open up a Powershell or CMD terminal
• Run python .\test_debugpy_issue.py
• Note the provided PID
• *Run > start debugging > * Attach to process with PID noted above
• Add breakpoint on line 10 in test_debug_issue_simplified.py
• Go back to terminal and press ENTER
• Step over to line 12 in Vs Code
• Step over line 12

The debugger freezes at subprocess.call. Running the script without debugging works just fine.

Extension version: 2023.6.0
VS Code version: Code 1.77.1 (b7886d7461186a5eac768481578c1d7ca80e2d21, 2023-04-04T23:21:11.906Z)
OS version: Windows_NT x64 10.0.19045
Modes:
Sandboxed: No

System Info

Item	Value
CPUs	Intel(R) Xeon(R) Platinum 8272CL CPU @ 2.60GHz (4 x 2594)
GPU Status	2d_canvas: unavailable_software canvas_oop_rasterization: disabled_off direct_rendering_display_compositor: disabled_off_ok gpu_compositing: disabled_software multiple_raster_threads: enabled_on opengl: disabled_off rasterization: disabled_software raw_draw: disabled_off_ok skia_renderer: enabled_on video_decode: disabled_software video_encode: disabled_software vulkan: disabled_off webgl: unavailable_software webgl2: unavailable_software webgpu: disabled_off
Load (avg)	undefined
Memory (System)	16.00GB (8.30GB free)
Process Argv	. --crash-reporter-id 9b1252ae-b8bc-46bc-a7ab-9ad131591069
Screen Reader	no
VM	0%

A/B Experiments

vsliv368:30146709
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
vstes627:30244334
vslsvsres303:30308271
vserr242:30382549
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
pythondataviewer:30285071
vscod805cf:30301675
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
cmake_vspar411:30581797
vsaa593:30376534
pythonvs932:30410667
cppdebug:30492333
vscaac:30438847
vsclangdf:30486550
c4g48928:30535728
dsvsc012cf:30540253
pynewext54:30695312
azure-dev_surveyone:30548225
nodejswelcome1:30587005
282f8724:30602487
pyind779:30671433
f6dab269:30613381
pythonsymbol12:30671437
vsccsb:30705552
pythonb192cf:30669361
azdwalk:30687957
pythonms35:30701012
j16hj152:30706079

[amine-aboufirass]

I noticed that launching subprocess.call with shell=True and adding "subProcess": true to launch.json fixes the freezing behavior.

However, I'm trying to debug a third-party code base which makees extensive use of shell=False so it would be great to understand why setting shell=False is a problem for debugpy.

[int19h]

shell=True means that the subprocess that gets spawned immediately is a shell process rather than a Python process, so subprocess debugging doesn't kick in at all. You should be getting the same effect from setting "subProcess":false.

The real issue here is that we simply don't support subprocess debugging in combination with attach-to-PID at the moment. Unfortunately, this went unnoticed when we changed the default for "subProcess" to be true, which is why you get this behavior. We should also probably show an error message if "subProcess" is used at all in an "attach" configuration (it doesn't actually apply because subprocess detouring has to happen in the debuggee before attaching, so it's configured via debugpy.configure()).

[amine-aboufirass]

Here's the behavior I'm seeing:

shell in subprocess.call	subProcess in launch.json	Can step over subprocess.call in script?
True	true	Yes
False	true	No
False	false	No
True	false	Yes

So it looks to me that the subProcess flag in launch.json has no effect on the debugger's step-over behavior. It's mostly related to setting subprocess.call(... , shell=True).

[int19h]

For attach configurations, "subProcess" in launch.json is not applicable in any attach scenario, because by the time the debuggee sees the config, it is already too late to apply the necessary changes to the process. That's why you need to use either the API - debugpy.configure(subProcess=...) - or the CLI - debugpy --configure-subProcess ... - to change it.

[gramster]

I will add this to the FAQ.