[Linux] GZDoom crashing when ZScript mod is combined with Dehacked weapon.

[FEZ_GG]

I'm trying to apply a ZScript mod that reduces the weapon switch speed of all weapons. The code that I'm using has the following format across all weapons:

class BFGNew: BFG9000 replaces BFG9000
{
Default
{
Weapon.SlotNumber 7;
}
States
{
Deselect:
BFGG A 1 A_Lower(18);
Loop;
Select:
BFGG A 1 A_Raise(18);
Loop;
}
}

For the most part this works fine. However, I decided to test this with the mapset Struggle: Antaresian Legacy, which uses extensive Dehacked to change the enemies and weapons. Most of the weapons cooperate with the new lower/raise speed, but the Leichenfaust, the BFG replacement, isn't cooperating. Shortly after I fire the weapon, before the projectile makes contact with anything, GZDoom will crash. I'm given the error "Address not mapped to object (signal 11) Address: 0x7fff57c0eff0".

I tried removing my States changes, and even the SlotNumber change so I had no new code when inheriting from BFG9000. That did not solve the issue. I also noticed that when firing the Leichenfaust, it still used 40 cells for ammo, when it's supposed to use 6 rockets. I tried adding Weapon.Ammotype = "RocketAmmo"; and Weapon.AmmoUse = 6; to see if that would resolve the issue, but it did not. At this point I'm not sure what to do. The original Leichenfaust, with no ZScript meddling, will work perfectly. It's only when I try to add a new BFG weapon in ZScript that issues arise. I can only assume there's some sort of conflict with Struggle's Dehacked file. The new BFG states call unusual pointers, like CheckReload and CloseShotgun2.

I'm running this on GZDoom 4.10.0 on my Steam Deck.

[wildweasel]

Can you upload your file to test? Dropbox, Google Drive, or whatever service works best for you.

[FEZ_GG]

Just uploaded it to Dropbox.
https://www.dropbox.com/scl/fi/c6lfmxmy ... 73aad&dl=0

[Player701]

I get a stack overflow in the VS debugger on Windows. From the stack trace, it looks like A_GunFlash is called initially and attempts to play the flash animation starting from the same state where it was called, which results in an endless chain of A_GunFlash calls. Essentially, the equivalent of this code:

Code: Select all

class CrashWeapon : Weapon
{
    ...
    
    States
    {
        ...

        Flash:
            TNT A 0 A_GunFlash; // Results in a stack overflow
            Stop;
    }
}

I'm aware that DECORATE/ZScript and DEHACKED do not play nice together when it concerns replacements, but this certainly looks like a bug to me. Therefore, I think this thread should be moved to Bugs.

For the record, here is the link to the WAD the OP is talking about. And the following ZScript code is enough to reproduce the issue:

Code: Select all

class NewBFG : BFG9000
{
}

Simply load this up along with strg.wad, type give NewBFG and attempt to fire - BOOM! stack overflow.

Reproduced in GZDoom 4.11.3 and g4.12pre-105-g22203cbc1.

[Graf Zahl]

The bug is on the mod side. A_GunFlash is what starts the flash state so you cannot use it from the initial flash state as it'd just repeatedly do the same thing all over again.
It is one of those things where the presence of data hacking like Dehacked does makes it quite impossible to do efficient error checks.

[Player701]

The bug is on the mod side.

If it is, then why doesn't it appear when running only strg.wad without any ZScript?

Upd: Just in case my previous post may have been wrongly interpreted: The first snippet of code is just a showcase to explain what is essentially happening that leads to the crash. To reproduce it, only the second snippet is required, which is just an empty class declaration. That's why I think this is a bug, and not a user error.

[Graf Zahl]

If you try to mix Dehacked and DECORATE/ZScript mods all bets are off.
The DECORATE inheritance is done first, taking the state indices from the, in this case, original BFG.

Now Dehacked comes along and alters the states. If it also alters the state labels of the original BFG but not your copy's so now your inherited weapon points to states that are not what it expects them to be.
The gist of it: You cannot mix Dehacked mods with actor replacements. There is no way to handle this.

[Player701]

The gist of it: You cannot mix Dehacked mods with actor replacements.

Well, that's not in question. I only thought it would at least not crash like that.

Looks like the real issue here is that stack overflow in the VM is not handled gracefully.

[Rachael]

Looks like the real issue here is that stack overflow in the VM is not handled gracefully.

Already reported that, but it looks like it's not currently fixable.

[Graf Zahl]

What we really need for these cases is a crash log with clear text function names, but the obstacles the compiler vendors put in the way for that are utterly ridiculous. Even C++20's stacktrace feature won't work without debug symbols.