Windows - Using Debugger causes Crash
jrdoughty opened this issue · comments
In https://github.com/jrdoughty/InvaderSupremacy I tried adding the debugger to my Main.hx file. However unless I comment out the line new debugger.HaxeRemote(true, "127.0.0.1"); in the main function, I can't get a successful compliation.
my launch.json file contains:
{
"version": "0.2.0",
"configurations": [
{
"name": "Windows Debug",
"type": "hxcpp",
"request": "launch",
"stopOnEntry": true,
"args":[
"compilePath=${workspaceRoot}",
"compileCommand=haxelib run openfl build Project.xml windows -64 -lib -hxcpp-debugger -debug -cpp -DHXCPP_DEBUGGER -Dfdb -Dtelemetry",
"runPath=${workspaceRoot}/export/windows/cpp/bin/",
"runCommand=RTS.exe",
"runInTerminal=false"
]
}
]
}
am I missing something simple?
I get this when I compile:
Compiling...
Compile succeeded!
Launching application...
Client not yet connected, does it call new HaxeRemote(true, 'localhost') ?
I also can connect with telnet on port 6972
Hi @jrdoughty - hmm, seems like I saw this on Mac at some point -- ah yes, #23. The way the debugger works, that line instantiates the debugger and will block until it connects.
It's especially crazy that telnet can connect. Maybe it's a firewall issue? Maybe telnet has permission, but your app doesn't? Maybe try disabling the Windows Firewall entirely?
I've disabled it and it still isn't connecting. I should clarify, I use telnet 127.0.0.1 6972 and it appears it connects connects but doesn't say anything in the terminal.
Hmm, interesting. Try mkdir C:\tmp, change permissions to everyone-writable, rerun the debugger, and look at the C:\tmp\adapter.log -- there should be a line like this:
1450452095.19971: VSCHS: Listening for client connection on localhost:6972 ...
This shows the hostname / IP it's listening on. Maybe it's listening on a name like myhostname or an IP address like 192.168.0.100 -- match exactly that hostname/ip and port exactly in your code, e.g.:
new debugger.HaxeRemote(true, "192.168.0.100", 6972);
I got this:
1459998519.942: VSCHS: Listening for client connection on localhost:6972 ...
1459998520.783: Starting: RTS.exe, pid=1120
1459998520.783: PM: Monitoring process: 1120
1459998523.825: Client not yet connected, does it call new HaxeRemote(true, 'localhost') ?
1459998523.825: Sending 159 bytes:
1459998523.825: {"type":"event","body":{"category":"console","output":"Client not yet connected, does it call new HaxeRemote(true, 'localhost') ?\n"},"event":"output","seq":4}
1459998524.568: VSCHS: Received connection from 127.0.0.1.
1459998524.583: Got message: OK
1459998524.634: Got message: ThreadStopped(0,7,debugger.HaxeRemote,new,debugger/HaxeRemote.hx,73)
1459998524.634:
Thread 0 stopped in debugger.HaxeRemote.new() at debugger/HaxeRemote.hx:73.
1459998524.634: VSCH: got cmd: Files
1459998524.634: VSCH: got cmd: FilesFullPath
1459998524.634: VSCH: got cmd: SetCurrentThread(0)
1459998524.634: VSCH: got cmd: WhereCurrentThread(false)
1459998526.633: VSCHS: Error while reading message from client: Custom(EOF)
1459998526.638: PM: Detected process exit: -1073741571
mThread = new DebuggerThread(this, startStopped); is the line it refers to on the ThreadStopped message
Ah, so it is getting connected. Shoot, then I think we're at the typical Mac / Windows problem (the recursive Files enum is causing crashes), which is being worked on (maybe even close to fixed) now: #25 (comment)
crud, ok well then I'll wait patiently :)
@jcward has the glorious day arrived????
@larsiusprime Perhaps! I haven't tested it yet. :P :)
@larsiusprime @jrdoughty Ok, I've updated the repo and instructions wrt PR #31 / #19 fixes. However, I did a quick test on Windows, and breakpoints still weren't working. So while I don't think everything's fixed, I think I got farther than before.
If you guys feel like giving it a try, you may need to remove the old debugger haxelib (I had it named wrong in the old instructions anyway):
haxelib remove debugger
And install hxcpp-debugger per the new instructions. Then change your -lib debugger statements to -lib hxcpp-debugger (or for OpenFL -- <haxelib name="hxcpp-debugger" if="debug" />)
I have redone my haxelib of the debugger, but I'm still getting:
Compiling...
Compile succeeded!
Launching application...
Client not yet connected, does it call new HaxeRemote(true, 'localhost') ?
https://github.com/jrdoughty/RTSBase/tree/VSCodeDebugging I've started testing it on my base RTSBase project and have all of the test files in that branch. I added all of the OpenFL things needed, and I have redownloaded the extention into my %USERPROFILE%.vscode\extentions folder.
Thanks for giving this a try, @jrdoughty, and for the pointer to your testcase. I was able to get this up and running with the debugger on Linux:
After adding the following "linux" section to the launch.json:
{
"name": "Linux Debug",
"type": "hxcpp",
"request": "launch",
"stopOnEntry": true,
"args":[
"compilePath=${workspaceRoot}",
"compileCommand=lime build linux -debug",
"runPath=${workspaceRoot}/export/linux64/cpp/bin/",
"runCommand=RTS",
"runInTerminal=false"
]
}
I've been waiting for the Windows version to compile for probably 20 minutes (running in a VM on my poor wee chromebook...) I may have to go to bed and check-in in the morning. :)
Oh, wow, look at that, many moons later, it's working in Windows for me:
So I'm guessing, it's got to be something related to your network / firewall configuration. Here's mine:
Can you ping localhost in a cmd prompt? I notice mine resolves to ::1 -- that's an IPv6 equivalent to 127.0.0.1, I believe. What does it say if you run hostname?
Wow, I'm really sorry I missed the responses. I need to change my filter settings in my gmail.
I've shut off my firewall under all scenarios and I can ping my localhost no problem. I was able to get it to work flawlessly on a linux box, so I know what the flow should look like, but it appears something is definately stopping it from working on my computer.
My hostname result is FireDragon-PC which seems correct.
I just updated Haxe to 3.3 and got the latest hxcpp version as well.
This is my current build config:
{
"name": "Windows: Build and Debug",
"runtimeExecutable": "${execPath}",
"args": [
"compilePath=${workspaceRoot}",
"compileCommand=haxelib run lime build windows -debug -Dfdb -DHXCPP_DEBUGGER",
"runPath=${workspaceRoot}/export/windows/cpp/bin/",
"runCommand=RTS.exe",
"runInTerminal=false"
],
"type": "hxcpp",
"request": "launch",
"stopOnEntry": true
}
This is my current result:
Compiling...
export/windows/cpp/haxe/ApplicationMain.hx:80: characters 47-65 : Warning : Use programPath instead
Compile succeeded!
Launching application...
VSCode then has an error that says: Debug adapter process has terminated unexpectedly
The Game then hangs, seemingly attempting to connect.
The adapter.log says this on its last line: VSCHS: Received connection from 127.0.0.1.
The Game then hangs, seemingly attempting to connect.
FYI, this won't help your specific problem, but in a8cc7ef Cauê added the ability for your program to know whether it's being debugged, so it doesn't have to hang, via a check like this:
#if (debug && HXCPP_DEBUGGER)
new debugger.HaxeRemote(true, "localhost");
if (Sys.getEnv("HXCPP_DEBUG") != null) {
new debugger.HaxeRemote(true, "localhost");
}
#end
Ok, back back to your problem. Hmm, the note that the Debug adapter process has terminated unexpectedly means something crashed in the debugger code (a missing file, directory, unexpected debugger message, something.)
The last line of the adapter.log is from here -- interestingly that's in a sub-thread launched off the main debug adapter. What are the last 5-10 lines of the adapter.log (I'm curious what the last message is from the main thread)? The main thread should be waiting in this loop -- presumably nothing should crash there... You could pepper more log statements in the VSCHaxeServer.hx.
There was an update in the protocol with hxcpp-debugger (I thought we had a nice error message for protocol mismatches, but maybe not) -- if you installed it with:
haxelib git hxcpp-debugger https://github.com/HaxeFoundation/hxcpp-debugger
Then perhaps update it? Either git pull or haxelib remove then install it again?
I ran the git hxcpp command and then tried recompiling. I'm still getting the debug adapter error afterward, so I'm going to try recompiling some things.
This was the last 5 lines from adapter.log:
1473385866.054: cmd: RTS.exe
1473385866.054: args: RTS.exe
1473385866.06: VSCHS: Listening for client connection on localhost:6972 ...
1473385866.3: Starting: RTS.exe, pid=8016
1473385866.3: PM: Monitoring process: 8016
1473385866.631: VSCHS: Received connection from 127.0.0.1.
Also I did the check you suggested, and it appeared to work, but I've removed it since I started seeing the debug console again spitting out:
Client not yet connected, does it call new HaxeRemote(true, 'localhost') ?
I'm sure that's not a bad thing, but until this works I figure I'll keep that check out.
I'm going to try rebuilding and resetting up everthing, see if a fresh start helps
Palm Meets Face It worked like a charm after I recompiled vscode-hxcpp-debug
I'm good to go now! Thanks for all the help, sorry this appears to have been an issue either my setup or the particular version of the windows debugger I'd been running.
Ah, excellent, glad it's working! I'll close this for now, then.