This is an issue I regularly (but intermittently) experience while using breakpoints to work on Friday Night Funkin'.
Sometimes, I will set a breakpoint, and when the application hits it, the game closes immediately with no error message.
Thankfully, this time I was able to reliably reproduce it, so I attached another C++ debugger (I use Visual Studio 2019 for this purpose). I can see here that the application is experiencing a stack overflow.
Based on the call stack, what appears to be happening is:
- The appropriate breakpoint is hit in the application.
- This calls
stack->mDebugger->Break(breakStatus, breakpointNumber, 0);, which calls g_eventNotificationHandler(...), which calls Server.handleThreadEvent.
- The application reaches line 540, and queries the status of the
currentThreadInfo:
|
if (currentThreadInfo.status == ThreadInfo.STATUS_STOPPED_BREAK_IMMEDIATE) { |
currentThreadInfo is null here. This throws a null object reference in the application.
- To handle the exception,
__hxcpp_dbg_fix_critical_error() gets called, which... attempts to trigger a breakpoint in the application at the location of the null object reference; this calls Server.handleThreadEvent, and on line 540 it attempts to query the status of currentThreadInfo, causing a null object reference. To handle the exception...
A straightforward solution here would be, since Server.hx is written in Haxe, to make the JSONRPC server null-safe by adding @:nullSafety to the class and fixing all compilation errors that appear as a result.
It should also be determined why currentThreadInfo is even null in the first place.