KEMBAR78
Use SIGTERM instead of SIGKILL when ending processes, allow attachSimplePort=0 · Issue #630 · microsoft/vscode-js-debug · GitHub
Skip to content

Use SIGTERM instead of SIGKILL when ending processes, allow attachSimplePort=0 #630

@alexkli

Description

@alexkli

Describe the bug

(Note sure if bug or feature request is most appropriate, this might be a somewhat special case!)

wskdebug is a debugging tool for Apache Openwhisk (a serverless platform), which starts a container with a nodejs process inside that will have the actual debug port to which the VS Code debugger should connect. I am using this in VS Code as runtimeExecutable and have been intercepting the --inspect-brk=NNNN argument that was set by the previous debugger to use this port on the container that gets started. VS Code then did connect to the container, which was great.

However, it seems the new debugger uses a different mechanism. Apparently it sets NODE_OPTIONS with a --require that loads a JS file into the node process that apparently sets up the debugging from "inside" the process.

The problem is that now it debugs the wskdebug "intermediary" and not the target container.

Is there a way in the new debugger I can disable that and just get hold off the port number (which VS code randomly chooses, i.e. in case there are multiple debug sessions going on)?

See also apache/openwhisk-wskdebug#74

On a related note, the new debugger seems to kill the process at the end immediately (SIGKILL style). The previous debugger sent a SIGTERM so that the process had a chance to cleanup and properly exit. In wskdebug case this is used to stop the docker container amongst other things. With the new debugger this is no longer possible and thus the container with the open debug port is left behind, so that the next run usually fails with "debug port already in use". This is also an artifact of the above issue since always the same default debug port (9229) is picked now since --inspect-brk=NNNN with a unique port NNNN is missing.

To Reproduce
Steps to reproduce the behavior:

  1. Run launch config with wskdebug as described here
  2. Notice debugger connects to wskdebug itself, but not the container it starts
  3. Cannot hit any breakpoints since it's debugging the wrong process

Log File

vscode-debugadapter-9.json.gz

VS Code Version: 1.47.1

Metadata

Metadata

Assignees

Labels

feature-requestRequest for new features or functionalityverification-neededVerification of issue is requestedverifiedVerification succeeded

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions