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

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

Moderator: GZDoom Developers

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

Postby dpJudas » Wed Dec 04, 2019 2:13 pm

You can check that theory by checking if (pc == sfunc->Code) and error out if it is.
dpJudas
 
 
 
Joined: 28 May 2016

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

Postby phantombeta » Wed Dec 04, 2019 2:33 pm

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
phantombeta
In the meadow of sinful thoughts, every flower's a perfect one
 
Joined: 02 May 2013
Location: Brazil, South America, Earth, Orion-Cygnus Arm, Milky Way
Discord: phantombeta#2461
Twitch ID: phantombeta_
Github ID: Doom2fan
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

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

Postby Player701 » Wed Dec 04, 2019 11:56 pm

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.
User avatar
Player701
 
Joined: 13 May 2009
Location: Russia
Discord: Player701#8214
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

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

Postby dpJudas » Thu Dec 05, 2019 1:11 am

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.
dpJudas
 
 
 
Joined: 28 May 2016

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

Postby Player701 » Thu Dec 05, 2019 1:17 am

OK, I'll see if I can get it to trigger with a release build tonight.
User avatar
Player701
 
Joined: 13 May 2009
Location: Russia
Discord: Player701#8214
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

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

Postby Nash » Thu Dec 05, 2019 4:47 pm



Still happens with latest fixes from master
User avatar
Nash
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Github ID: nashmuhandes

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

Postby phantombeta » Thu Dec 05, 2019 4:52 pm

As expected. Like I said before, this one's most likely a bug in the AsmJit library itself :wink:
User avatar
phantombeta
In the meadow of sinful thoughts, every flower's a perfect one
 
Joined: 02 May 2013
Location: Brazil, South America, Earth, Orion-Cygnus Arm, Milky Way
Discord: phantombeta#2461
Twitch ID: phantombeta_
Github ID: Doom2fan
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

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

Postby Player701 » Fri Dec 06, 2019 10:11 am

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).
User avatar
Player701
 
Joined: 13 May 2009
Location: Russia
Discord: Player701#8214
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Previous

Return to On Hold Bugs

Who is online

Users browsing this forum: No registered users and 0 guests