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

Is there something that doesn't work right in the latest GZDoom? Post about it here.

Moderator: GZDoom Developers

Forum rules
Please construct and post a simple demo whenever possible for all bug reports. Please provide links to everything.

If you can include a wad demonstrating the problem, please do so. Bug reports that include fully-constructed demos have a much better chance of being investigated in a timely manner than those that don't.

Please make a new topic for every bug. Don't combine multiple bugs into a single topic. Thanks!

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

Postby drako » Mon Jan 21, 2019 8:23 pm

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
drako
 
Joined: 08 Jan 2016

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

Postby Graf Zahl » Tue Jan 22, 2019 3:23 am

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.
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

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

Postby drako » Tue Jan 22, 2019 7:53 am

I assumed (incorrectly) that the problem is replicable. I attach the crash report. My system: MS Surface Book 2 15''.
Attachments
CrashReport.zip
x64
(43.66 KiB) Downloaded 9 times
drako
 
Joined: 08 Jan 2016

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

Postby Ozymandias81 » Tue Jan 22, 2019 2:55 pm

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)
User avatar
Ozymandias81
Doom is a State of Mind... Out of Control.
 
Joined: 04 Jul 2013
Location: Mount Olympus, Mars
Github ID: Ozymandias81
Operating System: Windows Vista/7 64-bit
Graphics Processor: nVidia (Modern GZDoom)

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

Postby _mental_ » Tue Jan 22, 2019 3:04 pm

Crash on loading is most likely a duplicate of this report.
Crash while shooting is something different. Is it purely random?
_mental_
 
 
 
Joined: 07 Aug 2011

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

Postby Ozymandias81 » Tue Jan 22, 2019 3:18 pm

_mental_ wrote: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.
User avatar
Ozymandias81
Doom is a State of Mind... Out of Control.
 
Joined: 04 Jul 2013
Location: Mount Olympus, Mars
Github ID: Ozymandias81
Operating System: Windows Vista/7 64-bit
Graphics Processor: nVidia (Modern GZDoom)

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

Postby AFADoomer » Tue Jan 22, 2019 7:02 pm

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.
User avatar
AFADoomer
 
Joined: 15 Jul 2003

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

Postby drako » Tue Jan 22, 2019 9:25 pm

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.
Attachments
CrashReport_x64_257.zip
(39.57 KiB) Downloaded 8 times
drako
 
Joined: 08 Jan 2016

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

Postby _mental_ » Wed Jan 23, 2019 6:27 am

drako wrote: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_
 
 
 
Joined: 07 Aug 2011

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

Postby _mental_ » Wed Jan 23, 2019 10:03 am

I found one code generation issue that causes implicit initialization to fail.
Spoiler: Script
Spoiler: Generated code

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.
_mental_
 
 
 
Joined: 07 Aug 2011

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

Postby Graf Zahl » Wed Jan 23, 2019 10:05 am

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.
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany


Return to Bugs

Who is online

Users browsing this forum: No registered users and 0 guests