Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Debugger Dies in Multiprocessing Env #1767

Open
95anantsingh opened this issue Jan 20, 2024 · 18 comments
Open

Debugger Dies in Multiprocessing Env #1767

95anantsingh opened this issue Jan 20, 2024 · 18 comments
Assignees
Labels
needs repro Issue has not been reproduced yet

Comments

@95anantsingh
Copy link

95anantsingh commented Jan 20, 2024

Type: Bug

Behaviour

Expected vs. Actual

Launching a debugger instance when multiprocessing is involved causes the debugger to exit without any error.
When process.join() is added to the code it works fine but not without it.

Steps to reproduce:

Add a breakpoint at time.sleep(5) line and wait few seconds

import time
from multiprocessing import Process

class MyClass:
       
    def run(self):
        process = Process(target=self.launch)
        process.start()
        # process.join()

    def launch(self):
        print("Started")
        time.sleep(5) # Try to add breakpoint at this line
        print("Finished")

if __name__ == "__main__":
   obj = MyClass()
   obj.run()

Diagnostic data

  • Python version (& distribution if applicable, e.g. Anaconda): 3.12.1
  • Type of virtual environment used (e.g. conda, venv, virtualenv, etc.): Global
  • Value of the python.languageServer setting: Default
Output for Python in the Output panel (ViewOutput, change the drop-down the upper-right of the Output panel to Python)

2024-01-19 21:34:43.647 [info] Using launch configuration in workspace folder.
2024-01-19 21:34:43.730 [info] DAP Server launched with command: /opt/homebrew/bin/python3.12 /Users/<user>/.vscode/extensions/ms-python.python-2023.22.1/pythonFiles/lib/python/debugpy/adapter
2024-01-19 21:34:43.828 [info] Send text to terminal:  cd /Projects/Dummy ; /usr/bin/env /opt/homebrew/bin/python3.12 /Users/<user>/.vscode/extensions/ms-python.python-2023.22.1/pythonFiles/lib/python/debugpy/adapter/../../debugpy/launcher 62517 -- /Projects/Dummy/test.py 
2024-01-19 21:34:44.300 [info] Connecting to DAP Server at:  127.0.0.1:62515
2024-01-19 21:34:44.311 [info] Connecting to DAP Server at:  127.0.0.1:62515

User Settings


languageServer: "Pylance"

Extension version: 2023.22.1
VS Code version: Code 1.85.2 (Universal) (8b3775030ed1a69b13e4f4c628c612102e30a681, 2024-01-18T06:40:32.531Z)
OS version: Darwin arm64 23.2.0
Modes:
Connection to 'attached-container+7b22636f6e7461696e65724e616d65223a222f6a756e6f2d646576222c2273657474696e6773223a7b22636f6e74657874223a226465736b746f702d6c696e7578227d7d' could not be established

System Info
Item Value
CPUs Apple M2 Pro (12 x 24)
GPU Status 2d_canvas: enabled
canvas_oop_rasterization: enabled_on
direct_rendering_display_compositor: disabled_off_ok
gpu_compositing: enabled
multiple_raster_threads: enabled_on
opengl: enabled_on
rasterization: enabled
raw_draw: disabled_off_ok
video_decode: enabled
video_encode: enabled
vulkan: disabled_off
webgl: enabled
webgl2: enabled
webgpu: enabled
Load (avg) 2, 2, 2
Memory (System) 16.00GB (0.33GB free)
Process Argv --crash-reporter-id fc29a4f7-357a-4d7f-83aa-04d4ff4a2ca6
Screen Reader no
VM 0%

Connection to 'attached-container+7b22636f6e7461696e65724e616d65223a222f6a756e6f2d646576222c2273657474696e6773223a7b22636f6e74657874223a226465736b746f702d6c696e7578227d7d' could not be established

A/B Experiments
vsliv368cf:30146710
vspor879:30202332
vspor708:30202333
vspor363:30204092
vscod805:30301674
binariesv615:30325510
vsaa593:30376534
py29gd2263:30899288
vsclangdc:30486549
c4g48928:30535728
azure-dev_surveyone:30548225
a9j8j154:30646983
0bi6i642:30933247
pythongtdpath:30769146
welcomedialog:30910333
pythonidxpt:30866567
pythonnoceb:30805159
asynctok:30898717
pythontestfixt:30902429
pythonregdiag2:30936856
pyreplss1:30897532
pythonmypyd1:30879173
pythoncet0:30885854
pythontbext0:30879054
accentitlementst:30887150
dsvsc016:30899300
dsvsc017:30899301
dsvsc018:30899302
dsvsc019acf:30933242

Tasks

Preview Give feedback
No tasks being tracked yet.
@karthiknadig karthiknadig transferred this issue from microsoft/vscode-python Jan 22, 2024
@paulacamargo25
Copy link

Thanks for the bug report and sorry for the delay, could you send me your launch.json configuration? Thanks

Copy link

Hey @karthiknadig, this issue might need further attention.

@95anantsingh, you can help us out by closing this issue if the problem no longer exists, or adding more information.

@95anantsingh
Copy link
Author

95anantsingh commented Sep 8, 2024

@karthiknadig
@paulacamargo25
@vs-code-engineering

I used the default launch.json

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Python Debugger: Current File",
            "type": "debugpy",
            "request": "launch",
            "program": "${file}",
            "console": "integratedTerminal"
        }
    ]
}

Copy link

Hey @karthiknadig, this issue might need further attention.

@95anantsingh, you can help us out by closing this issue if the problem no longer exists, or adding more information.

Copy link

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.

Happy Coding!

@vs-code-engineering vs-code-engineering bot closed this as not planned Won't fix, can't repro, duplicate, stale Nov 9, 2024
@karthiknadig karthiknadig reopened this Nov 9, 2024
@karthiknadig karthiknadig added the bug Something isn't working label Nov 10, 2024
@karthiknadig
Copy link
Member

This looks like a bug in Debugpy.

@karthiknadig karthiknadig removed the bug Something isn't working label Dec 11, 2024
@karthiknadig karthiknadig removed their assignment Dec 11, 2024
@karthiknadig karthiknadig transferred this issue from microsoft/vscode-python-debugger Dec 11, 2024
@github-actions github-actions bot added the needs repro Issue has not been reproduced yet label Dec 11, 2024
@rchiodo
Copy link
Contributor

rchiodo commented Dec 11, 2024

Closing as this is an old bug and we haven't seen any other people reporting this.

@rchiodo rchiodo closed this as completed Dec 11, 2024
@rchiodo
Copy link
Contributor

rchiodo commented Dec 11, 2024

Tested it and it works for me with 3.13

@95anantsingh
Copy link
Author

95anantsingh commented Dec 11, 2024

@rchiodo I tested it, its still there. Should I send a video?

@rchiodo
Copy link
Contributor

rchiodo commented Dec 11, 2024

Make sure you're using the latest version of debugpy. If you're inside VS code, make sure it's the prerelease version of the debugpy extension. If you're doing this manually, make sure it's the latest debugpy (which is 1.8.9 at the moment)

@95anantsingh
Copy link
Author

After switching to pre release version (v2024.13.2024112901 (pre-release)) it takes longer to die, around 40 sec. But it still does. I am not sure how to get the internal version of debugpy at the extensions tab I could only see v2024.13.2024112901 (pre-release).

@rchiodo
Copy link
Contributor

rchiodo commented Dec 11, 2024

You're saying your breakpoint is never hit? For me it hits the breakpoint just fine:

Image

If you never hit the breakpoint, you can turn on logging as described here:
https://github.com/microsoft/debugpy/wiki/Enable-debugger-logs

The pydevd log should tell us if something didn't work. Maybe there's a path mapping issue.

@95anantsingh
Copy link
Author

It hits, but wait there for 40 seconds and the process will exit without intervention. Ideally it should stay alive indefinitely.

@rchiodo
Copy link
Contributor

rchiodo commented Dec 11, 2024

Oh that makes sense though. You're not waiting for the subprocess in the main process. The main process exits and so the child process is killed.

@rchiodo
Copy link
Contributor

rchiodo commented Dec 11, 2024

I think the only way to do what you want would be to attach to the subprocess instead.

@95anantsingh
Copy link
Author

95anantsingh commented Dec 11, 2024

As I have observed the debugger attaches to subprocess as well in this code automatically.
Ideally debugger should not exit. And there is no explanation why it takes 40 secs if debugger is not attached to subprocess. It should immediately exit.

Another thing is that this doesn't happen with threads

@rchiodo
Copy link
Contributor

rchiodo commented Dec 11, 2024

Threads wouldn't have this problem. The main thread wouldn't exit because the other thread is at a breakpoint (meaning all threads are suspended).

The weird part is the 40 seconds though. I agree it should exit almost immediately.

@rchiodo
Copy link
Contributor

rchiodo commented Dec 11, 2024

Looking at the logs from a run, the child process isn't killed by the debugger. I think VS code might be shutting it down.

Pydevd log shows this for the subprocess as the last item:

0.01s - Process StackTraceRequest: {
    "arguments": {
        "format": {},
        "levels": 19,
        "startFrame": 1,
        "threadId": 1
    },
    "command": "stackTrace",
    "seq": 18,
    "type": "request"
}

0.00s - Created frame id source reference: 2 for frame id: 1603371027808 (<string>)
0.00s - sending cmd (http_json) -->           CMD_RETURN {"type": "response", "request_seq": 18, "success": true, "command": "stackTrace", "body": {"stackFrames": [{"id": 6, "name": "run", "line": 108, "column": 1, "source": {"path": "C:\\Users\\rchiodo\\AppData\\Local\\Programs\\Python\\Python313\\Lib\\multiprocessing\\process.py", "sourceReference": 0}, "presentationHint": "subtle"}, {"id": 7, "name": "_bootstrap", "line": 313, "column": 1, "source": {"path": "C:\\Users\\rchiodo\\AppData\\Local\\Programs\\Python\\Python313\\Lib\\multiprocessing\\process.py", "sourceReference": 0}, "presentationHint": "subtle"}, {"id": 8, "name": "_main", "line": 135, "column": 1, "source": {"path": "C:\\Users\\rchiodo\\AppData\\Local\\Programs\\Python\\Python313\\Lib\\multiprocessing\\spawn.py", "sourceReference": 0}, "presentationHint": "subtle"}, {"id": 9, "name": "spawn_main", "line": 122, "column": 1, "source": {"path": "C:\\Users\\rchiodo\\AppData\\Local\\Programs\\Python\\Python313\\Lib\\multiprocessing\\spawn.py", "sourceReference": 0}, "presentationHint": "subtle"}, {"id": 10, "name": "<module>", "line": 1, "column": 1, "source": {"path": "<string>", "sourceReference": 2}}], "totalFrames": 6}, "seq": 56, "pydevd_cmd_id": 502}

So it never receives a terminate, meaning the main process exiting doesn't actually cause it to die.

But in the vscode logs, I can see this in the log for the subprocess:

29624 Client <-- Adapter:
{
    "seq": 29,
    "type": "event",
    "event": "terminated"
}
29646 Client --> Adapter:
{
    "command": "disconnect",
    "arguments": {
        "restart": false
    },
    "type": "request",
    "seq": 16
}
29647 Client <-- Adapter:
{
    "seq": 30,
    "type": "response",
    "request_seq": 16,
    "success": true,
    "command": "disconnect"
}
29649 Stopping Session
29650 Error:
{}

Which looks like we get the terminated event and then some time later, VS code disconnects (sends the disconnect command).

There might be a bug here in that the subprocess is sending a terminate event.

@rchiodo rchiodo reopened this Dec 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs repro Issue has not been reproduced yet
Projects
None yet
Development

No branches or pull requests

4 participants