ZDoom

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

by **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

by **Nash** » Thu Dec 05, 2019 4:47 pm

Still happens with latest fixes from master

by **Player701** » Thu Dec 05, 2019 1:17 am

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

by **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.

by **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.

by **phantombeta** » Wed Dec 04, 2019 2:33 pm

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.

by **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.

by **phantombeta** » Wed Dec 04, 2019 1:49 pm

Graf Zahl wrote:I also do not believe that the level rewrite messed things up, it never interacts with the VM's innards. The only thing I know is that it revealed some major architectural issues with the event handling but that's on a far higher level.

Not for the JIT errors, but it would explain the random VM abort at level start.

By the way, I think I may have identified that bloody menu error.
This line checks the previous opcode by doing "pc - 1". While usually there would be stuff before it, I'm guessing in some rare case (perhaps a function call with no arguments at the start of a function), it's the first thing in the code, so "pc - 1" ends up in random data, and that random data sometimes ends up being equal to OP_VTBL. It should probably have some check to see if "pc" is at the start of the code, I guess.

by **Graf Zahl** » Wed Dec 04, 2019 7:25 am

Nash wrote:Something I failed to mention in the past; I noticed that these "mysterious errors" starting popping up after the level rewrite was merged into master. And I mean the whole bunch - invalid instruction mov, unexplainable VM aborts, etc. I can say with 90% certainty that these things have never happened before said merge.

Edit for clarification: I am not blaming the level rewrite, perhaps it's not related at all... but I remember clearly _when_ these started manifesting.

I also do not believe that the level rewrite messed things up, it never interacts with the VM's innards. The only thing I know is that it revealed some major architectural issues with the event handling but that's on a far higher level.

by **dpJudas** » Wed Dec 04, 2019 7:06 am

Nash wrote:Something I failed to mention in the past; I noticed that these "mysterious errors" starting popping up after the level rewrite was merged into master. And I mean the whole bunch - invalid instruction mov, unexplainable VM aborts, etc. I can say with 90% certainty that these things have never happened before said merge.

Edit for clarification: I am not blaming the level rewrite, perhaps it's not related at all... but I remember clearly _when_ these started manifesting.

I don't think the level rewrite can cause this. If anything, it was some other scripting backend related change during the same period that started it. The most likely candidate to the error is either that A) the JitCompiler compiler class receives a VM register index that is out of bounds, B) it itself fails to initialize an asmjit virtual register, or C) asmjit messes up its internal state.

We could add some validation for it in the JitCompiler, but I'd rather invest my time on my own IR backend. The unwind code in GZD is sort of a ticking time bomb in the sense that its extremely low level, IMO should be done by asmjit, and doesn't seem to become a feature there unless I add it myself (which I can't).

Graf Zahl wrote:Regarding JIT in general, it's really a shame that there's no way to create Visual Studio debugger info for scripted content - if that existed a lot more of the engine could be scriptified.

I'm actually not sure if that is impossible or not. Visual Studio is able to display the call stack for .net JIT code. The big question here is whether they implemented that in some .net specific way, or if it looks for a HMODULE header next to the function table. If it is the latter then it might be possible to give the functions names and reference source files.

by **Nash** » Wed Dec 04, 2019 6:48 am

Something I failed to mention in the past; I noticed that these "mysterious errors" starting popping up after the level rewrite was merged into master. And I mean the whole bunch - invalid instruction mov, unexplainable VM aborts, etc. I can say with 90% certainty that these things have never happened before said merge.

Edit for clarification: I am not blaming the level rewrite, perhaps it's not related at all... but I remember clearly _when_ these started manifesting.

by **Graf Zahl** » Wed Dec 04, 2019 6:30 am

dpJudas wrote:Ibut its code is written in such a way that I have no idea how to even begin writing a proper PR for it.

Welcome to the club! I got the same problem with a certain other project I'm working on (I guess you know what I mean

), it's also written in a way that makes it very, very hard to implement stuff in a sane manner.

Regarding JIT in general, it's really a shame that there's no way to create Visual Studio debugger info for scripted content - if that existed a lot more of the engine could be scriptified.

by **dpJudas** » Wed Dec 04, 2019 5:55 am

I have a script compiler that I originally wrote to output to LLVM. Then due to the issues we also had when I used it for GZD I wrote my own backend that was more or less API compatible with the IRBuilder in LLVM. So it is like a mini-llvm with the same general compiler strategy.

In my current version of the IR backend I'm using asmjit for register allocation and lowering it to x64 opcodes, but I'm working on writing my own register allocator and x64 asm writer. Once I'm done with that I'll have a complete compiler backend that can JIT with no external dependencies.

For GZD this means I can actually do certain things that I kind of hacked asmjit into doing: providing unwind info to the OS. It will also allow me to actually code optimization passes and get rid of the 256 virtual register limit that asmjit has. I wish I could have added these things to asmjit, but its code is written in such a way that I have no idea how to even begin writing a proper PR for it.

by **Graf Zahl** » Wed Dec 04, 2019 5:16 am

Now you really made me curious...

ZDoom

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

Post a reply

Expand view Topic review: [4.0.0, possibly earlier] "Invalid Instruction: mov"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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