VSCode debugging

bbrinkmann

Hi all, I'm finally getting some traction building FeathersUI apps using VSCode, but I'm hitting a couple of issues when debugging macOS targets. For context, following the FeathersUI Getting Started steps for using VSCode (https://feathersui.com/learn/haxe-openfl/visual-studio-code/), and created and ran a Hello World app call "Starter".

1) After setting a breakpoint on the super() call within the Starter new() function, debugging causes the following error banner when the breakpoint is hit:

"Exception has occurred. X
Null Object Reference"

FWIW, this doesn't happen on HTML5/Debug targets.

2) After this exception, or any other exception that prevents the macOS app from continuing, the process is left hanging and has to be manually killed.

3) I have so far been unable to debug the .cpp code (breakpoints don't break), but I'm guessing that's due to my lack of experience with this setup.

Any help or feedback is appreciated.

joshtynjala

I'll be honest. I don't usually try to launch any cpp targets in a debugger unless I'm working on an issue that specifically affects cpp only because I hate waiting for the extra long compile times. HashLink is probably closest to cpp in behavior, since it is also a native target, so you might consider trying that for debugging instead. Much faster compile times.

bbrinkmann 3) I have so far been unable to debug the .cpp code (breakpoints don't break), but I'm guessing that's due to my lack of experience with this setup.

Like adding breakpoints in .cpp files? I don't think that will work. As I understand it, the hxcpp debugger requires adding breakpoints to the original .hx files.

Be sure to that your target is set to macOS/Debug, and if you had previously compiled a non-debug build, make sure that you compile a clean build because sometimes switching from non-debug to debug results in an executable that can't actually be debugged or has weird crashes. Something in the toolchain seems to try to use some kind of cache that occasionally gets stale. A clean build usually fixes that. In fact, that might actually be what could fix 1) and 2) as well.

bbrinkmann

@joshtynjala, thanks for looking at this.

I installed the VSCode HashLink extension and tried to build the Lime HashLink target, but I get the message, "HashLink debugging on macOS is not supported yet.", for all versions (HashLink, HashLink / Debug, and HashLink / Final). I looked through the GitHub issue the extension pointed me to (https://github.com/vshaxe/hashlink-debugger/issues/28) and I also found the discussion you started on the Haxe forum (https://community.haxe.org/t/compiling-hashlink-on-macos-apple-silicon/3150), but I'm not clear where it all stands. Wondering if I have to build my own, whether it has to be x86_64, and whether it will result in a VSCode extension. Any insights appreciated.

I may eventually want to debug the resulting cpp code as I will be integrating with a custom cpp library. But for now, if possible, I thought it might shed light on the null object reference exception I mentioned above.

I set and ran build task 'lime clean hl -debug --connect 6001', but still had the same issue.

joshtynjala

You're right, the currently released version of the Lime VSCode extension doesn't yet allow HashLink debugging on macOS. Originally, HashLink itself didn't support debugging on macOS at all, but they finally added support later, and our extension is a bit behind. A while back, I actually enabled HashLink debugging in lime-vscode-extension on GitHub, but we haven't released an update including that change yet. It's been over a year since our last release, so I'll try to prioritize that soon. Sorry for pointing you toward something that doesn't quite work yet on macOS.

bbrinkmann

joshtynjala Thanks again and no worries. I've got plenty to keep me busy and my new Mac is fast enough to tolerate the cpp compiles for now. 🙂

I would like to figure out the Haxe new() breakpoint exception, but I suspect it's related to under the hood objects being uninitialized at that point. I'll find a way to move the code I want to examine after initialization..