ZDoom

Thanks a ton! This opens up room for more experiments to optimize my script code even further.

Very much appreciated. :)

[url=https://github.com/ZDoom/gzdoom/pull/1686]PR#1686[/url]

It seems the cause is [url=https://github.com/coelckers/gzdoom/blob/a15d4e5/src/common/scripting/frontend/zcc_compile.cpp#L1371]this conditional[/url]. Partially-sized classes get their size changed from TentativeClass, which screws this conditional up and makes it start compiling a class whose parent hasn't been fully sized yet.

Some simple tests show this is affected by definition order. That indicates something's hitting one of the structs when it hasn't had its size calculated yet and messing the type's fields' alignment and the type's size because of that.

Here's some additional information about this issue that might be useful in resolving it:

[list=1][*]It doesn't have to do anything with abstract functions (replacing [c]abstract[/c] with [c]virtual[/c] and adding an empty body does not change the behavior).
[*]It has something to do with structs.
[*]In particular, it has something to do with structs that have other structs as members.
[*]It also has something to do with the order in which the structs are defined (moving the definition of [c]MyInnerStruct[/c] to before [c]MyStruct[/c] resolves the crash).
[*]The crash itself appears to be a side-effect of memory corruption (crashes somewhere in the [c]FString[/c] code, complaining about invalid pointers).
[*]The crash [i]might[/i] have something to do with inheritance, or it could be just a more efficent way of triggering it (merging the classes [c]Base[/c] and [c]Derived[/c], in this case, resolves the crash).[/list]
I first encountered this issue while rewriting the UI code in my project to use structs (to work around [url=https://forum.zdoom.org/viewtopic.php?f=2&t=70492]this bug[/url], as it seems that it's not going to get fixed in the foreseeable future), and then had quite a difficult time attempting to isolate it. Aside from this particular issue, user-defined structs in ZScript do seem to suffer from several other drawbacks, and are thus not suitable for production use yet (IMHO).

class TestInv : Inventory
{
    override bool TryPickup(in out Actor toucher)
    {
        let d = new('Derived');
        
        d.test = "12345";
        d.F1();
    
        GoAwayAndDie();
        return true;
    }
}

class Base abstract
{
    MyStruct s;

    void F1()
    {
        s.Value1 = 1;
        F2();
    }
    
    protected abstract void F2();
}

class Derived : Base
{    
    String test;
    
    override void F2()
    {
        Console.Printf("Calling F2");
        Console.Printf(test); // BOOM
    }
}

struct MyStruct
{
    int Value1;
    MyInnerStruct Inner;
}

struct MyInnerStruct
{
    int Value2;
}

Sorry, I have no idea how I can be more specific in the thread title. The following ZScript can be used to reliably crash GZDoom with a very fatal error:

[code]class TestInv : Inventory
{
override bool TryPickup(in out Actor toucher)
{
let d = new('Derived');

d.test = "12345";
d.F1();

GoAwayAndDie();
return true;
}
}

class Base abstract
{
MyStruct s;

void F1()
{
s.Value1 = 1;
F2();
}

protected abstract void F2();
}

class Derived : Base
{
String test;

override void F2()
{
Console.Printf("Calling F2");
Console.Printf(test); // BOOM
}
}

struct MyStruct
{
int Value1;
MyInnerStruct Inner;
}

struct MyInnerStruct
{
int Value2;
}[/code]
To reproduce, load the script file and go to any map, then type [c]give testinv[/c] in the console. The crash will happen immediately when the engine attempts to print the value of [c]test[/c] during the call to [c]Derived::F2[/c].

Tested in GZDoom 4.7.0 and g4.8pre-4-g3ef60a40a.