[4.0.0, possibly earlier] "Invalid Instruction: mov"

[dpJudas]

You can check that theory by checking if (pc == sfunc->Code) and error out if it is.

[phantombeta]

Yep. Turns out there's a similar line that does the same in VM calls. Putting it on both makes it spit out many of those errors.
Gonna push a fix for that.

[Edit]: Pushed a fix.

[Player701]

Reporting test results. Since phantombeta's fix for the menu error, I've run GZDoom 3360 times with a test version of my mod, and no invalid instruction errors have appeared. I cannot conclude that the error is gone, of course, but yesterday (before the fix) I ran GZDoom about 1500 times and got 4 invalid instruction errors (mov <None>, qword [rbp+16]).

I also cannot say anything about the address zero error, because I haven't got any since I first started testing. I've been using debug builds, and it may be possible that the error only happens in release builds for some reason. I will test release builds too, when I have the time.

[dpJudas]

You generally can't use debug builds to test for errors that may be caused by uninitialized variables. The debug C runtime clears all data with 0xcd when allocating and 0xfe when freeing it, which effectively means an uninitialized variable might no longer get the value that can trigger the bug.

[Player701]

OK, I'll see if I can get it to trigger with a release build tonight.

[Nash]

Still happens with latest fixes from master

[phantombeta]

As expected. Like I said before, this one's most likely a bug in the AsmJit library itself

[Player701]

Release build testing results:

• GZDoom g4.3pre-389-gb9367caa6 (includes phantombeta's fix) was run 2329 times with a test version of my mod. No errors of any kind were encountered.
• For comparison, I also tested GZDoom g4.3pre-388-ga07d7856c, which does not have the fix. Of the 2267 test runs, there were 5 invalid instruction errors and 3 write to address zero errors.

So, regardless of what Nash says, I'd say this is fixed... at least for me. Maybe Nash's project has something that triggers a bug in some other place of GZDoom source (like phantombeta said, could be the asmjit library).

It is also interesting that all address zero errors seemed to have the same stack trace this time. Unfortunately, I couldn't get the exact stack trace again - I was running GZDoom with +logfile, but none of the errors appeared in my logs (this may be yet another bug). I only know the errors happened because I set my script to take a screenshot of GZDoom's window in case of a crash (I couldn't leave GZDoom windows open because my laptop could've run out of memory).