HXCPP Debugging Breakpoint Crashes App

[phanxgames]

Problem:

Setting up a very basic example project, where the Main.hx extends openfl.display.Sprite and within the constructor I setup the HaxeRemote lines, etc.

I am not able to run a breakpoint in the Main class, or any other class, as long as it extends Sprite.
When the app runs in debug mode it loads fine, it appears the debugger attaches, and things are going to be okay. But then about a second after the breakpoint is hit, my program process crashes, ending debugging.

If I create a class that does not extend any other class, the break point works as expected.
But if I change the stack in the Debugger pane to a class that extends Sprite, my program process crashes and ends debugging.

I tried to narrow this down before I reported the issue here, but I was not able to make any rhyme or reason to the behavior of when the breakpoints crash my program or not. I can make the debugging crash or not crash based on if I comment out properties in my extended class, but even that isn't consistent. All properties were simply "public var test1:Int = 1;" etc.

I looked around through all consoles in the IDE and no error appears beyond:
"Information:Debugging loop failed: Haxe Exception: IOException: java.net.SocketException: Connection reset"
Which is to be expected if the program process crashes.

Just to note, I was able to run the openfl project in non-debug mode just fine, so my general config appears to be fine.

Hope my information helps! Thank you.

Additional information

Project config:

• openfl 8.9.7
• lime 7.7.0
• hxcpp 4.1.1
• hxcpp-debugger 1.1.0

Environment:

• Intellij IDEA Ultimate v2019.3
• Windows 10

[trnzk]

I also faced this crash. For my case, the problem was not in the plugin. While serializing classes, there was a stack overflow in the application. To avoid this, I changed the HxCreateDetachedThread function in the include/hx/Thread.h file in hxcpp. I chose the 50MB stack size but maybe it could be smaller.

inline bool HxCreateDetachedThread(void *(*func)(void *), void *param)
{
	pthread_t t;
	pthread_attr_t attr;
	if (pthread_attr_init(&attr) != 0)
		return false;

#ifdef HXCPP_DEBUGGER
   if (pthread_attr_setstacksize (&attr, 50 * 1024 * 1024) != 0)
      return false;
#endif      

#ifdef PTHREAD_CREATE_DETACHED
	if (pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED) != 0)
		return false;
#endif
	if (pthread_create(&t, &attr, func, param) != 0 )
		return false;
	if (pthread_attr_destroy(&attr) != 0)
		return false;
	return true;
}

#endif

[phanxgames]

What is the default stack size?
And if I were to change this as well, would I need to compile hxcpp myself?

[trnzk]

I use macos for development, that change is also for macos. If our problem is the same, you have to make this change for windows. The second parameter of the CreateThread function refers to the stack size. You can write a value of 50MB here and see if the problem is solved. The default stack size will vary depending on the OS.

For windows, find the function below:

inline bool HxCreateDetachedThread(DWORD (WINAPI *func)(void *), void *param)
{
	return (CreateThread(NULL, 0, func, param, 0, 0) != 0);
}

and change it like this:

inline bool HxCreateDetachedThread(DWORD (WINAPI *func)(void *), void *param)
{
#ifdef HXCPP_DEBUGGER
	return (CreateThread(NULL, 50*1024*1024, func, param, 0, 0) != 0);
#else
        return (CreateThread(NULL, 0, func, param, 0, 0) != 0);
#endif
}

After this change, rebuild your application. For release builds, use default stack value.

[EricBishton]

I have a sneaking suspicion that this is because the code that tries to display the value uses the class itself to generate the value that is displayed to the user. That is: toString() (or whichever method hxcpp is using these days) in the openFL classes is chasing a circular reference trying to create the output. (e.g. Sprite has a member variable pointing to the Display, which, in turn keeps references to its Sprites, and both of them are trying to call the other in order to build an output string for the debugger.)

I'll verify, but the solution is probably in hxcpp and/or openFL. hxcpp should be trapping the overflow and returning a string like "Stack Overflow occurred," rather than just crashing.