Incompatible with VSCode 1.5.0+
renehamburger opened this issue · comments
I haven't managed to get this extension to run on VSCode 1.8.1 on Windows 10. Is your example launch.json still up-to-date? The compiler complains about the "cwd" property being missing, for example.
It also complains about the launch type "hxcpp" being unknown, even though the extension seems to have been installed correctly. The built of the extension passed and it's displayed as installed within VSCode. Is it possible that your package.json needs updating, too?
Personally I've tried messing with the package.json and couldn't get any difference
The /tmp/adator.log file shows:
1483975710.46462: Reading 241 bytes...
1483975710.4647: {"command":"initialize","arguments":{"adapterID":"hxcpp","pathFormat":"path","linesStartAt1":true,"columnsStartAt1":true,"supportsVariableType":true,"supportsVariablePaging":true,"supportsRunInTerminalRequest":true},"type":"request","seq":1}
1483975710.46473: Got command: initialize
1483975710.46474: Initializing...
1483975710.46475: Sending 55 bytes:
1483975710.46475: {"command":"initialize","success":true,"request_seq":1}
Maybe they changed the handshake? Seems like an odd thing to do...
I never have been able to get hxcpp debugger working. I am receiving
Debugger:Starting App side debugger support. Debugger:Failed to connect to debugging server at 127.0.0.1:6972 : EOF Debugger:Trying again in 3 seconds.
but I did notice in 1.8.1 removing `
"runtimeExecutable": "${execPath}",
"args": [
"compilePath=${workspaceRoot}",
"compileCommand=nme build windows project.nmml",
"runPath=${workspaceRoot}/build/nme/windows/project/",
"runCommand=project",
"runInTerminal=false"], `
Makes "type":"hxcpp" acceptable...IDK
Just leaving myself some comments:
- The initialization sequence (or communication protocol) changed somehow. vscode does not respond to my response to the "initialize" command.
- I noticed a new "initialized" event, but it gets sent after the "launch" command, and we're not getting there yet.
- Looking at .ts source / examples: debugProtocol.ts, debugSession.ts, and goDebug.ts
- The limited docs on the debug protocol state:
If your adapter is derived from the TypeScript or C# default implementation DebugSession, you don't have to handle the initialize request yourself.
- Great, so that means they can change it without much notice.
- The break occurred between 1.4 (working) and 1.5.0 (no longer working), both available from the updates page. Note that 1.5 is packaged for linux differently, in a .tar.gz file instead of a .zip. TODO: investigate changes between 1.4 and 1.5.0 more closely.
Users can verify this looking at /tmp/adapter.log -- the last things that happens is we send a response to the "initialize" command:
1489161088.78874: Reading 241 bytes...
1489161088.78884: {"command":"initialize","arguments":{"adapterID":"hxcpp","pathFormat":"path","linesStartAt1":true,"columnsStartAt1":true,"supportsVariableType":true,"supportsVariablePaging":true,"supportsRunInTerminalRequest":true},"type":"request","seq":1}
1489161088.78887: Got command: initialize
1489161088.78888: Initializing... _run_process is: null
1489161088.7889: ----> Sending 65 bytes:
1489161088.7889: {"body":{},"command":"initialize","success":true,"request_seq":1}
@jcward Since we are still on version 1.x of the debug protocol we are not allowed to break the protocol (and we have not heard of any broken debugger since we've shipped VS Code 1.0). However, we have added quite a few features to the debug protocol in a backward compatible way.
In order to verify that nothings breaks when we change or add something to the debug protocol, I use the mono-debug extension which does not rely on the JS/TS debugadapter npm module: https://github.com/Microsoft/vscode-mono-debug
I've reviewed the change history of mono-debug but I could not find any commit that would explain the problem you are seeing.
I tried to build your haxe debug extension, but the build steps are incomplete (I do not have haxe installed).
I quickly looked into your implementation but I could not find that your debug adapter sends a "InitializedEvent" to VS Code. It could be that earlier versions of VS Code were more resilient if this event was missing. But it was always a required event. Here is the corresponding doc:
Since VS Code persists breakpoints on behalf of the debug adapter, it has to register the breakpoints with the debug adapter when a session starts. Since VS Code does not know when is a good time for this, the debug adapter is expected to send an initialize event to VS Code to announce that it is ready to accept breakpoint configuration requests.
I suggest to send this event at the end of your "initialize" handler (after you have sent the "initialize" response). See how this is done in mono-debug or mock-debug.
@weinand -- thank you so much for the detailed response. I saw InitializedEvent -- but in the Go adapter, it appears to be sending InitializedEvent in the launchRequest handler, not in the initializeRequest handler... Is this not correct? In the mock, I saw it in the initializeRequest handler, but I assumed this was because mock doesn't actually initialize anything. And the Go schema made more sense -- until my app is launched, I can't actually handle breakpoints (though I could queue them, maybe.)
I'm pretty sure I also tried sending an InitializedEvent in my InitializeRequest handler to no effect, but I'll double check. I did also notice that if I set a breakpoint in VSCode, a different sequence of init events happens and leads to a bad state. I'll try to characterize that further as well.
Thanks again for your time.
@jcward The "InitializedEvent" triggers a whole sequence of requests in VS Code, one being the request to set breakpoints in your debug adapter. It depends on your debug adapter when this should happen. The doc says: "Since VS Code does not know when is a good time for this, the debug adapter is expected to send an initialize event to VS Code to announce that it is ready to accept breakpoint configuration requests."
node-debug has the same problem as hack-debug: it cannot accept breakpoints before the node programm is launched. So node-debug sends the "InitializedEvent" late.
@weinand - I've created a simple Ruby script that mimics the init behavior of my debug adapter to test initialization sequences. I'm working on Linux, but it should also work on OSX. You can place it in my debug adapter at vscode-hxcpp-debug/bin/linux/vschxcppdb (and ensure it's executable, chmod a+x vschxcppdb)
It logs all incoming commands at /tmp/echo.log and responds to the initialize command with a success message. You can comment or uncomment the send_event({"event"=>"initialized"}) line.
There are 4 logs below -- in vscode 1.4 and 1.8, each with and without the initialized events.
In VSCode 1.4, with or without the initialized event, vscode sends a "launch" command right after the InitializeResponse.
In VSCode 1.8 (and anything after 1.5), the behavior is: if I don't send an initialized event, it hangs and does not respond. If I do send an initialized event, it requests my threads. What?! How is it legitimate for VSCode to request threads when it hasn't sent a launch command yet?
So if I don't send an initialized event, it hangs, and if I do, it asks for thread before launching. What am I to do?
VSCode 1.4, without the initialized event:
Got message: {"type"=>"request", "seq"=>1, "command"=>"initialize", "arguments"=>{"adapterID"=>"hxcpp", "pathFormat"=>"path", "linesStartAt1"=>true, "columnsStartAt1"=>true, "supportsVariableType"=>true, "supportsVariablePaging"=>true}}
Sending 32 bytes: {"success":true,"request_seq":1}
Got message: {"type"=>"request", "seq"=>2, "command"=>"launch", "arguments"=>{"name"=>"OSX/Linux: Debug", "args"=>["runPath=/home/jward/dev/vscode-hxcpp-debug/test cli/export", "runCommand=Main-debug", "runInTerminal=true"], "type"=>"hxcpp", "request"=>"launch", "program"=>"", "stopOnEntry"=>true}}
WARNING: Got unknown command: launch, ignoring...
VSCode 1.4, with the initialized event:
Got message: {"type"=>"request", "seq"=>1, "command"=>"initialize", "arguments"=>{"adapterID"=>"hxcpp", "pathFormat"=>"path", "linesStartAt1"=>true, "columnsStartAt1"=>true, "supportsVariableType"=>true, "supportsVariablePaging"=>true}}
Sending 32 bytes: {"success":true,"request_seq":1}
Sending 46 bytes: {"event":"initialized","seq":1,"type":"event"}
Got message: {"type"=>"request", "seq"=>2, "command"=>"launch", "arguments"=>{"name"=>"OSX/Linux: Debug", "args"=>["runPath=/home/jward/dev/vscode-hxcpp-debug/test cli/export", "runCommand=Main-debug", "runInTerminal=true"], "type"=>"hxcpp", "request"=>"launch", "program"=>"", "stopOnEntry"=>true}}
WARNING: Got unknown command: launch, ignoring...
VSCode 1.8 without the initialized event:
Got message: {"command"=>"initialize", "arguments"=>{"adapterID"=>"hxcpp", "pathFormat"=>"path", "linesStartAt1"=>true, "columnsStartAt1"=>true, "supportsVariableType"=>true, "supportsVariablePaging"=>true, "supportsRunInTerminalRequest"=>true}, "type"=>"request", "seq"=>1}
Sending 32 bytes: {"success":true,"request_seq":1}
VSCode 1.8 with the initialized event:
Got message: {"command"=>"initialize", "arguments"=>{"adapterID"=>"hxcpp", "pathFormat"=>"path", "linesStartAt1"=>true, "columnsStartAt1"=>true, "supportsVariableType"=>true, "supportsVariablePaging"=>true, "supportsRunInTerminalRequest"=>true}, "type"=>"request", "seq"=>1}
Sending 32 bytes: {"success":true,"request_seq":1}
Sending 46 bytes: {"event":"initialized","seq":1,"type":"event"}
Got message: {"command"=>"threads", "type"=>"request", "seq"=>2}
WARNING: Got unknown command: threads, ignoring...
With mock-debug I see this sequence of requests and events:
got initializeRequest
send InitializedEvent
got launchRequest
got threadsRequest
got threadsRequest
got stackTraceRequest
got scopesRequest
got scopesRequest
got scopesRequest
got scopesRequest
With the exception of the two threadsRequest this looks correct to me.
Ok, luckily debugging release versions of VSCode is super easy with command Developer: Toggle Developer Tools. Stepping through the protocol, I found my first problem, where my response was being discarded. In VSCode rev 68ac40, message.type became required (before it was implied as response if not an event.) This is my fault, as the mock debug message type has always said type is a required field. Easy enough, fixed in a07ad8c.
There is still a problem with Thread ID's (I'm getting ErrorNoSuchThread(0)), but this error is on the hxcpp side. So the vscode compatibility issue should be resolved. Closing.
@jcward great to hear that you could resolve the issues!