[Fixed] [4.5.0/g638c49fe0] JIT CTD

[Accensus]

Tested on GZDoom 4.5.0 and g4.6pre-69-g638c49fe0. Happens on both.

Message itself:

Code: Select all • Expand view

JIT: sfunc->NumArgs != argsPos || regd > sfunc->NumRegD || regf > sfunc->NumRegF || rega > sfunc->NumRegA

Crash report: https://drive.google.com/file/d/1186rYH ... sp=sharing

There are no exact steps to reproduce because the only thing that triggers it is sometimes picking up DSDInterface from this addon for Hideous Destructor. It's completely random. I am not too sure what I'm doing that triggers this. Sometimes it happens when I start a new game on the HD range and just summon the thing to pick it up for the first time. It seems to only happen if I restart GZDoom and try again. Loading a save repeatedly doesn't seem to trigger it, or at the very least I couldn't get it to. I'll post updates if I find anything worth sharing.

EDIT: commented out all of my code that gets called when picking up an item and still managed to get it to crash a few times. But now I can no longer reproduce it.

[phantombeta]

That really ought to give you more info about where it occurred, and not tie together 4 different error conditions.

[_mental_]

The given error message has been changed to be more descriptive.

[Accensus]

Much appreciated. I'll run it again once I get my hands on a dev build and report which one of those it is.

[Rachael]

I'll run it again once I get my hands on a dev build and report which one of those it is.

I made one for you, so you don't have to wait: https://cdn.discordapp.com/attachments/ ... d07e5c8.7z

[Accensus]

Thank you! So the error seems to be:

Code: Select all • Expand view

JIT: inconsistent number of address registers for function DSDInterface.AttachToOwner

I'm not too sure what's different here compared to all the other times I've done this. Because I've done this at least one other time and I don't recall ever having any issues with that.

Code: Select all • Expand view

override void AttachToOwner(Actor other)
{
   Super.AttachToOwner(other);
   InitStorage(); // [Ace] Only finds the thinker. Does not add any items.
}

private void InitStorage()
{
   ItemStorage = DSDStorage.Get(owner.PlayerNumber());
}


[_mental_]

It somehow related to this commit that allows skipping optional arguments of the parent function in a virtual override definition.
The problem is, function prototype resolution may pick wrong entry in the following case.

Code: Select all • Expand view

class Base : Weapon
{
   virtual void Func(Actor a, bool b = true)
   {
   }
}

class Derived : Base
{
   override void AttachToOwner(Actor other)
   {
   }

   override void Func(Actor a)  // no second argument, AttachToOwner's prototype is picked
   {
   }
}

This leads to a wrong prototype being modified by prototype extension logic.

In the initial report, here is a virtual function, and here is an override.

[Accensus]

I have no idea how I've managed to miss that. Thank you for pointing it out, I'll go fix it on my end asap.

[Graf Zahl]

@_mental_: Where does the mismatch happen? Is this something solely tied to the JIT code or some bad management elsewhere?

[_mental_]

It has nothing to do with JIT. There are links to related code in my previous post. It's much better to look at this in the debugger though.

Here is the same sample again.

Code: Select all • Expand view

class Base : Weapon
{
   virtual void Func(Actor a, bool b = true)
   {
   }
}

class Derived : Base
{
   override void AttachToOwner(Actor other)
   {
   }

   override void Func(Actor a)  // no second argument, AttachToOwner's prototype is picked
   {
   }
}

For Derived.Func(), NewPrototype() function picks existing prototype from type table added there after processing of AttachToOwner() as they have the same prototype.
This prototype is later modified by PClass::FindVirtualIndex() as both functions share the same prototype. I guess that the problem is here.

[Graf Zahl]

Yes, that function really should not modify the prototype itself but instead call NewPrototype for the altered one. Strange that this never caused errors before.

[_mental_]

Something like this? Of course, it solves the JIT error only. Crash on exit is a different issue with attempt to use released Vulkan handles.

[_mental_]

Here is the updated version of the fix.