I've had 2.3.4 live for modding in APICO for a long time now and has been working great! Unfortunately over the last few months I've had some reports of random crashes related to modding and I've been trying to investigate but I use Apple Silicon so I have to run the game through Rosetta to have the dylib load as it's not built for the arch so I don't get any proper stacktraces.

All the errors only occur on Mac - I'm building with YYC on the latest GMS LTS (2022.0.3.85) and they all seem to be related to arrays being wrong or the wrong sizes to what's expected, array_set or array_gets with "variable [x] out of range [y]" crashes, as if Apollo is setting things in memory wrong? The lines thrown don't always seem to relate to anything with arrays, but there's a lot that point towards "lua_call()" and then I can't dig anymore.

Seemed to be find last year, so seems like a new Mac update (or LTS update) has come along to mess things up - anything I can do to try and get more info?

Apollo V2 (on GitHub) uses YYRunnerInterface, which could have per-platform bugs/differences.

Apollo V1 (latest on itch/marketplace) doesn’t do anything special, any time you access something from GML side, the extension function suspends the Lua state and returns, then another call resumes it with fetched value(s).

V1 is what it uses atm, I'd use V2 but looks like it isn't buildable for mac/linux yet?
The only things that has changed since Apollo was working last is MacOS has had some updates (15.X) and GM LTS had an update.

VM build works fine (however can't use VM as I need YYC for the steam extension) - I have had issues in the past with YYC builds on console having weird crashes around ds_* structures and pointers so seems to be something similar to that, I just can't get a proper stacktrace at the moment.

Is there a way I can build V1 from source so I can build it for Silicon? That way I could run YYC directly from GMS or Xcode and see the full stacktrace in the console.

Managed to get a few logs by messing with Rosetta:

array_set :: variable Index [2] out of range [1]", script : "gml_Script_lua_state_exec", message : "array_set :: variable Index [2] out of range [1]" }
{ line : 0, stacktrace : [ "gml_Script_lua_state_exec (line 18)","gml_Script_lua_call (line 8)","gml_Script_sc_menu_draw (line 194)"]

array_set :: variable Index [19] out of range [19]", script : "gml_Script_lua_state_exec", message : "array_set :: variable Index [19] out of range [19]" }

 { line : 0, stacktrace : [ "gml_Script_lua_state_exec (line 18)","gml_Script_lua_call (line 8)","gml_Object_co_mods_KeyPress_1 (line 12)" ]

array_set :: variable Index [19] out of range [5]", line : 0, stacktrace : [ "gml_Script_lua_state_exec (line 18)","gml_Script_lua_call (line 8)","gml_Object_ob_player_Draw_0 (line 71)" ]

They all trace back to a lua_call, the way it's being called hasn't changed in forever so I wonder if the state being passed in is getting read wrong somewhere due to YYC compilation? The state always comes from lua_current, however the lua_current references do get stored in a ds_map which is sometimes used to pass the state, I tried changing to structs but get the same crashes, and logging the state values all seems correct.

I guess only thing is how the scripts have got converted to CPP with YYC? I can send over the generated lua_state_exec and lua_call .cpp files if that would be helpful?

EDIT: Looks like this does happen on Windows too using YYC, I just haven't seen it reported as the Windows build is exported with VM only so hasn't come up before! I tried building Windows YYC just not and get all the same crashes so seems like it isn't specific to MacOS, just YYC in general.

AFAIK GM generates the same C++ code on YYC regardless of target platform so it is likely a behavior difference between C++ compilers on Windows/Mac. If you can replicate it in a smaller project, you could file a bug report for GM.

The source code should be included in the extension folder, or send me an email and I’ll send you the Visual Studio solution with Mac/Linux build scripts.