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

These bugs do plan to be resolved, when they can be.

Moderator: GZDoom Developers

dpJudas
 
 
Posts: 2893
Joined: Sat May 28, 2016 1:01 pm

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

Post by dpJudas »

You can check that theory by checking if (pc == sfunc->Code) and error out if it is.
User avatar
phantombeta
Posts: 2011
Joined: Thu May 02, 2013 1:27 am
Graphics Processor: nVidia with Vulkan support

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

Post by phantombeta »

Image
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.
User avatar
Player701
 
 
Posts: 1472
Joined: Wed May 13, 2009 3:15 am
Graphics Processor: nVidia with Vulkan support
Location: Russia

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

Post by 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
 
 
Posts: 2893
Joined: Sat May 28, 2016 1:01 pm

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

Post by 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.
User avatar
Player701
 
 
Posts: 1472
Joined: Wed May 13, 2009 3:15 am
Graphics Processor: nVidia with Vulkan support
Location: Russia

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

Post by Player701 »

OK, I'll see if I can get it to trigger with a release build tonight.
User avatar
Nash
 
 
Posts: 17326
Joined: Mon Oct 27, 2003 12:07 am
Location: Kuala Lumpur, Malaysia

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

Post by Nash »



Still happens with latest fixes from master
User avatar
phantombeta
Posts: 2011
Joined: Thu May 02, 2013 1:27 am
Graphics Processor: nVidia with Vulkan support

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

Post by phantombeta »

As expected. Like I said before, this one's most likely a bug in the AsmJit library itself :wink:
User avatar
Player701
 
 
Posts: 1472
Joined: Wed May 13, 2009 3:15 am
Graphics Processor: nVidia with Vulkan support
Location: Russia

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

Post by 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).

Return to “On Hold Bugs”