[g3.8pre-251-g4eea540a3] Blade of Agony crashes

[drako]

Download zip from https://github.com/Realm667/WolfenDoom .

[copied from viewtopic.php?f=19&t=47801&p=1088261#p1088261]

I have just downloaded the newest GitHub wolfendoom-master.zip and tried to run it with the newest gzdoom x64 (Jan 19 version). It crashes with access violation error when I try to play a map (either by using console MAP CxMy or by using "new game"). Is it just problem on my side or some of you have similar problems?

EDIT: It seems that x32 build (Jan 21, 251) works better, It crashes when I go to c1m1 (command map c1m1) but it does not crash on map c1m2-c1m5 (I did not test others). x64 crashes on all the above.

Error: Access Violation C00000005 tried to write address

[Graf Zahl]

I just tested it and did not get any crash. And since you did not even bother to attach the crash log (the entire Zip, please, and not just some extracted parts!) I have no idea what's up. It may be a bug, it may be an issue with your system or it may just be the alignment of the stars when you ran it.

[drako]

I assumed (incorrectly) that the problem is replicable. I attach the crash report. My system: MS Surface Book 2 15''.

[Ozymandias81]

Best way to replicate it is to run TEST_ACT map using console commands or from GZDoomBuilder test: 80% of times crashes, and may also happen when shooting at enemies. This happens as well with r228 on both 32-64bit, and r338 is not runnable at all
On c1m1 happens when you skip the introduction sequence via console command (map c1m1 then press Use to skip intro)

[_mental_]

Crash on loading is most likely a duplicate of this report.
Crash while shooting is something different. Is it purely random?

[Ozymandias81]

Crash on loading is most likely a duplicate of this report.
Crash while shooting is something different. Is it purely random?

While 64bit builds are quite impossible to run (228 and 251 32bit runs vanilla Doom btw), on TEST_ACT map random crashes happen oftenly, specially while shooting at Guard actors... Since the map has intentionally numerous portals and actors which uses zscript-decorate complex inheritances, I assume something may come from these sides. Not possible being specific unfortunately.

[AFADoomer]

It's entirely likely that this is another uninitialized variable issue... I'll try to scrub all of the BoA ZScript to eliminate those tonight.

[drako]

Maybe the following helps. In x86 build 251, when I map c1m2 I get the message in the log (in red, without crash): "Script error, "script00.lmp"line 1: Map does not define a namespace. The same message I get in map c1m5, map c3m1, map c3m2.
I observe the same behavior in x86 build 257.
x64 build 257 crashes on map c1m1 with access violation error (I attach the crash report).
It is quite strange that x86 and x64 builds behave differently.

[_mental_]

It is quite strange that x86 and x64 builds behave differently.

32-bit build has no JIT. If the crash is caused solely by it, running 64-bit GZDoom with +vm_jit 0 command line will "fix" it.

[_mental_]

I found one code generation issue that causes implicit initialization to fail.

---

Code: Select all • Expand view

class RegisterOverwrite : Actor
{
    Array<int> testArray1;
    Array<int> testArray2;

    override void BeginPlay()
    {
        testArray1.copy(testArray2);

        Actor testActor;
        console.printf("actor = %p", testActor);
    }
}

---

Code: Select all • Expand view

========================= RegisterOverwrite.BeginPlay =========================
Integer regs: 0    Float regs: 0    Address regs: 3    String regs: 0 
Stack size: 3

Constant integers:
  0. 1360             1. 1376           

Constant addresses:
  0. 000001F940649F20   1. 000001F9412296C0   2. 000001F93F852E20

Constant strings:
  0. actor = %p

Disassembly @ 000001F9412296D0:
00000000: cf010000 add     a1,a0,1360                   ;1,0,0
00000004: cf020001 add     a2,a0,1376                   ;2,0,1
00000008: 4d030100 param   a1                           ;3,1,0
0000000c: 4d030200 param   a2                           ;3,2,0
00000010: 50000200 call    [000001F940649F20],2,0       ;0,2,0  [DynArray_I32.Copy [Native]]
00000014: 4d060000 param   "actor = %p"                 ;6,0,0
00000018: 4d030100 param   a1                           ;3,1,0   <---------------------------------------- apparently this is wrong
0000001c: 4d070100 param   000001F9412296C0             ;7,1,0
00000020: 50020300 call    [000001F93F852E20],3,0       ;2,3,0  [Console.Printf [Native]]
00000024: 54808000 ret                                  ;128,128,0

Looks like we have incorrect register allocation somewhere. Moving testActor declaration before Array.Copy() fixes the problem. Registers used in the function no longer overlap.

[Graf Zahl]

This is no register allocation error, it's just the old and known problem that a reused register doesn't get cleared for the reuse.