-
Notifications
You must be signed in to change notification settings - Fork 7
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
Mac - app does not connect to the debug server #23
Comments
@jcward said: @mpoint4u thanks for the note. You can safely ignore those errors in launch.json. The latter are a bug in vscode ("node" isn't the only debug type that's accepted.) My debug adapter doesn't use "program" -- I suppose you could add "program":"" to make validation happy, but it hasn't caused problems for me without it. I think the app seems like it isn't launching because it's actually crashing near time 0. Check out
So in the above, the client starts (pid=13210) and connects, but after I send a couple commands (Files, FilesFullPath, SetCurrentThread, etc) the client disconnects (and I think crashes with the stack trace I put in the bug report above.) The /tmp/adapter.log file is available on linux and mac, and if you create a C:\tmp folder on windows, also there. |
@mpoint4u said: sorry, a little late ... but here is what I get in /tmp/adapter.log (PS: I am using Haxe Compiler 3.2.1 / hxcpp: [3.2.193] / lime: [2.7.0] with MacBook 64 bit on OSX El Capitan 10.11.2)
Later in the evening I will try to debug the DisplayingABitmap - test project in VS Code on 64bit Linux ... and see what I will get ... and report then ... |
Hi @mpoint4u - in your log, you can see that the client never connected -- in the below "disconnect" means you hit the stop button in the GUI: 1450452095.19971: VSCHS: Listening for client connection on localhost:6972 ... What're you're missing is: 1450216366.30884: VSCHS: Received connection from 127.0.0.1. Did you put the Thanks for your feedback! |
Hi Jeff, now I switched in the recompiled ... and ... ... it's still not connecting ... !! I will check all the other stuff, which could disrupt a socket connection on '127.0.0.1' How could I get a proof that the 'server part' of the hxcpp-debug-adapter effectively works on Mac OSX ... ?!? Cheers, ------- end of /tmp/adapter.log ----------------------------- 1450686481.20458: Sending 382 bytes: |
could it be that, for whatever reason, the current MacOSX operating system allows only port connections higher than 10000 on the local network interface ('127.0.0.1' or 'localhost') ... ?!? It just hits the eye that all client connections on '127.0.0.1' in my above screenshot are higher than that ... I had a quick Google research on that, but that did not reveal very much either ... |
While your vscode is sitting waiting for the connection, try:
or
From a terminal window. This will attempt to connect to the server. If you get "connection refused", then something with the network or server isn't working. If you get "Connected to localhost, Escape character is ^]" then it did connect, and the problem is on the client app side. Also, do i pull and rebuild (haxe build-mac.hxml) -- I put in some more error/warning messages that could help in pointing out issues. |
pmMacBookPro:Desktop marcus$ telnet 127.0.0.1 6972 server part seems to be OK ... so it should be the client ... |
full output for last attempt of compile & debug ...
1450713215.29324: Reading 124 bytes... 1450713225.17173: Sending 382 bytes: |
Did you pull and rebuild? There should be a warning that the client didn't reconnect. So then, make sure the app has all 3:
|
just tried another few things, but it looks like that the compiles client NOT EVEN tries to connect ... my Main.hx looks like this: package; import openfl.display.Bitmap; #if debug class Main extends Sprite {
#if debug
} and compiles without a halt .... |
but when I try to build it from the command line, I get .... openfl build mac -64 -debug -DHXCPP_DEBUGGER which does not look so good anymore (it's talking about NULL references etc) ... |
my launch.json now looks like this ... { |
Hmm, it seems like you have all the elements. I'll do some more Mac testing this evening and get back to you. It could also be interesting, while your code server is waiting for a connection, to try launching it from the commandline to see what your app says in the terminal. (I don't see the null references in the output above -- did you paste the whole output?) |
OK, I will check that later ... have to leave for meeting family at dinner ... ;-) |
Hi Jeff ... seems like I got the "Mac version" of the "Blue Screen of Death" on my MacBook now ... after some recherche I assume it will be something like so it looks like I am not able to investigate for some time on our issue... not particularely GOOD news, but ... anyway ... cheers & a happy holiday season !! |
Hi, I tried right now on osx and got the very same result. Any suggestions? |
@arthurferrai ah, ok, I'm not entirely familiar the conventions of OSX apps directory structure. So the |
@jcward the run path is ok, the problem is with run command. My entry is as follows:
|
That's interesting, have to try that !! ... (Just read that now, did not appear on my radar earlier / was also a few month away from computing due to family/moving/house stuff) ... |
Hi @mpoint4u -- I think the issue you're experiencing is different than #19, so I've moved it here to its own thread.
@mpoint4u said on Dec 16:
same happens to me, when I try to start the actual executable on 64bit Mac (in '/Export/mac64/cpp/bin/DisplayingABitmap.app/Contents/MacOS/DisplayingABitmap') from the command line (because it does not launch from VS Code directly ... )
and if I try to debug the compiled program from VS Code debug perspective (via launch.json) I get a few error messages for missing property 'program' or wrong type value ....

....
PS: I am using Haxe Compiler 3.2.1 / hxcpp: [3.2.193] / lime: [2.7.0] with MacBook 64 bit on OSX El Capitan 10.11.1
all in all ... VS Code seems to be a quite nice editor / debugging enviroment ... (have to try it on Linux soon ... )
The text was updated successfully, but these errors were encountered: