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

Sandbox must be disabled for VS Code remote debugging to work #17540

Closed
rhinck opened this issue Nov 14, 2022 · 2 comments · Fixed by #17566
Closed

Sandbox must be disabled for VS Code remote debugging to work #17540

rhinck opened this issue Nov 14, 2022 · 2 comments · Fixed by #17566
Assignees
Labels

Comments

@rhinck
Copy link

rhinck commented Nov 14, 2022

Describe the bug

Filed by request from @thejcannon

When running ./pants run --debug-apapter {path_to_target} and using Visual Studio Code's Python: Remote Attach feature, VS Code is able to attach to the remote debug server but breakpoints are never hit when Pants sandboxes are used. Breakpoints only work when the Pants sandbox is explicitly disabled.

Pants version
2.14.0

OS
macOS (haven't tested on Linux)

Additional info

@rhinck rhinck added the bug label Nov 14, 2022
@thejcannon thejcannon self-assigned this Nov 16, 2022
@thejcannon
Copy link
Member

Ahh I thought I remembered this working.

This "works" for the test goal but not the run goal because of the handshaking between the server and the client based on paths.

The important thing is:

                     "pathMappings": [
                         {
                             "localRoot": "/home/josh/work/pants",
                             "remoteRoot": "."
                         }
                     ],

In test the CWD is the sandbox, so files paths are truly relative to remoteRoot. However in run, CWD is the the project root, so this mapping doesn't apply.

Now to figure out how to adjust the mapping 😅

@thejcannon
Copy link
Member

microsoft/debugpy#1130

thejcannon added a commit that referenced this issue Nov 18, 2022
…unning in a sandbox (#17566)

Fixes #17540

The key is that the DAP client is sending `pathMappings`, which normally sets `remoteRoot` to `"."` which for `run` isn't true.
There's no easy way to have the server set it's own mapping so we monkeypatch.
thejcannon added a commit to thejcannon/pants that referenced this issue Nov 18, 2022
…unning in a sandbox (pantsbuild#17566)

Fixes pantsbuild#17540

The key is that the DAP client is sending `pathMappings`, which normally sets `remoteRoot` to `"."` which for `run` isn't true.
There's no easy way to have the server set it's own mapping so we monkeypatch.
thejcannon added a commit to thejcannon/pants that referenced this issue Nov 18, 2022
…unning in a sandbox (pantsbuild#17566)

Fixes pantsbuild#17540

The key is that the DAP client is sending `pathMappings`, which normally sets `remoteRoot` to `"."` which for `run` isn't true.
There's no easy way to have the server set it's own mapping so we monkeypatch.
thejcannon added a commit to thejcannon/pants that referenced this issue Nov 18, 2022
…unning in a sandbox (pantsbuild#17566)

Fixes pantsbuild#17540

The key is that the DAP client is sending `pathMappings`, which normally sets `remoteRoot` to `"."` which for `run` isn't true.
There's no easy way to have the server set it's own mapping so we monkeypatch.
thejcannon added a commit that referenced this issue Nov 18, 2022
…unning in a sandbox (Cherry-pick of #17566) (#17584)

Fixes #17540

The key is that the DAP client is sending `pathMappings`, which normally sets `remoteRoot` to `"."` which for `run` isn't true.
There's no easy way to have the server set it's own mapping so we monkeypatch.
thejcannon added a commit that referenced this issue Nov 18, 2022
…unning in a sandbox (Cherry-pick of #17566) (#17583)

Fixes #17540

The key is that the DAP client is sending `pathMappings`, which normally sets `remoteRoot` to `"."` which for `run` isn't true.
There's no easy way to have the server set it's own mapping so we monkeypatch.
thejcannon added a commit that referenced this issue Dec 8, 2022
Fixes #17672 and fixes #17692

Added new test-code which tests the `DebugAdapterRequest` by running it without `--wait-for-client`. This wouldn't catch issues like #17540 which require a client, but would catches issues like #17672 and #17692.

Fixes:
- Bad debugpy ICs
- Untracked issue where the process would always return 0
- The config wouldn't be used if provided
- Removes the reliance on `importlib_metadata` to load the entrypoint, instead re-enters the already executing pex in-process
thejcannon added a commit to thejcannon/pants that referenced this issue Dec 9, 2022
Fixes pantsbuild#17672 and fixes pantsbuild#17692

Added new test-code which tests the `DebugAdapterRequest` by running it without `--wait-for-client`. This wouldn't catch issues like pantsbuild#17540 which require a client, but would catches issues like pantsbuild#17672 and pantsbuild#17692.

Fixes:
- Bad debugpy ICs
- Untracked issue where the process would always return 0
- The config wouldn't be used if provided
- Removes the reliance on `importlib_metadata` to load the entrypoint, instead re-enters the already executing pex in-process
thejcannon added a commit that referenced this issue Dec 10, 2022
…17768)

Fixes #17672 and fixes #17692

Added new test-code which tests the `DebugAdapterRequest` by running it without `--wait-for-client`. This wouldn't catch issues like #17540 which require a client, but would catches issues like #17672 and #17692.

Fixes:
- Bad debugpy ICs
- Untracked issue where the process would always return 0
- The config wouldn't be used if provided
- Removes the reliance on `importlib_metadata` to load the entrypoint, instead re-enters the already executing pex in-process
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
2 participants