[Solved] Crash on Hideous Destructor, GZDoom 4.1.3

Need help running G/Q/ZDoom/ECWolf/Zandronum/3DGE? Did your computer break? Ask here.

Moderator: GZDoom Developers

Re: Crash on Hideous Destructor, GZDoom 4.1.3

Postby Matt » Fri Jul 12, 2019 2:07 pm

I think I've found the code in HD that causes this recursion, though I don't get why this wouldn't be happening with everyone else on a regular basis.

Can we move this to Technical Issues or something given this is obviously not a GZDoom bug but still ongoing discussion about the actual problem?
User avatar
Matt
Putting the XD into *xdeath since 2007
 
Joined: 04 Jan 2004
Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia

Re: Crash on Hideous Destructor, GZDoom 4.1.3

Postby PhysixCat » Sat Jul 13, 2019 1:22 pm

Matt recently added a check to HDMobAI.Chase to the master branch of Hideous Destructor
https://github.com/MatthewTheGlutton/HideousDestructor/commit/e67db26c67387705b2b008567a634f8912bc3269,
I just git pull'd to test it.

The discussed 'summon archangel and wait' still causes a crash, but the crashlog seems different. Maybe the fix was a step in the right direction, but there's still trouble elsewhere.

ZIP11 with the relevant gzdoomdebug.log, gzdoom.dmp, and gzdoom binary is here:
https://mega.nz/#!u90EQKjb!LQl_qPDA4NsF ... Qw92-LX5kg

(Do let me know if it's no longer necessary to provide the binary in the ZIP, since it's not a GZDoom bug. I will also only provide one ZIP per crash unless more are requested, to avoid redundancy)
User avatar
PhysixCat
 
Joined: 15 Jan 2019

Re: Crash on Hideous Destructor, GZDoom 4.1.3

Postby _mental_ » Sun Jul 14, 2019 2:47 am

If callstack contains ~20k entries, it's infinite recursion for sure.
Code: Select allExpand view
HDMobAI.chase
fighterimp.A_ImpChase
fighterimp.StateFunction.25
Actor.A_Look
Actor.SetState
Actor.SetStateLabel
HDMobAI.chase
fighterimp.A_ImpChase
fighterimp.StateFunction.25
...
_mental_
 
 
 
Joined: 07 Aug 2011

Re: Crash on Hideous Destructor, GZDoom 4.1.3

Postby Matt » Sun Jul 14, 2019 5:00 pm

Okay, this is completely beyond me then. There is no way that A_Chase call in that function could possibly becausing an infinite see/look loop (and if it were a lot of people would have reported it and I would have been able to replicate it by now).
User avatar
Matt
Putting the XD into *xdeath since 2007
 
Joined: 04 Jan 2004
Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia

Re: Crash on Hideous Destructor, GZDoom 4.1.3

Postby PhysixCat » Mon Jul 15, 2019 2:38 am

I have good news. I have found the source of the crash, in one of the last places I would have thought to check. The compatibility settings menu of GZDoom.

As it turns out, the Vanilla Essence mod https://forum.zdoom.org/viewtopic.php?t=59412 (which I do not use with Hideous Destructor) left its residual compat flag codes from its previous session in the gzdoom.ini file, even when it wasn't loaded or toggled. So, the crash was happening because even though Vanilla Essence was correctly restoring compatmode=0 after a session with it toggled on, it was not restoring compatflags=0 & compatflags2=0.

So in conclusion - the mystery crash with Hideous Destructor's blue magic and archangel resurrections? Some arcane interaction with compatflags in GZDoom, which were not returned to default by Vanilla Essence. I didn't think to check the compatflags until now because I just assumed that returning compatmode=0 automatically meant compatflags would also be =0, but I was wrong in that assumption.
User avatar
PhysixCat
 
Joined: 15 Jan 2019

Re: Crash on Hideous Destructor, GZDoom 4.1.3

Postby Graf Zahl » Mon Jul 15, 2019 4:12 am

Ugh.

That surely cannot work. Compatmode is just an umbrella CVAR that alters compatflags1 and compatflags2. Backing that up is utterly pointless because it doesn't represent the real compatiblity state. This really should back up the flags themselves.

The one responsible here should be compat_soundtarget. The HD code is not compatible with that, from a quick look (that target == null check in the Chase function should be disabled if that flag is active.)
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: [Solved] Crash on Hideous Destructor, GZDoom 4.1.3

Postby PhysixCat » Mon Jul 15, 2019 11:12 am

The one responsible here should be compat_soundtarget.


Yes, just confirmed this on my end. When compat_soundtarget = true, this causes the crash I've been talking about. None of the other compatflags seemed to do it, at least from the other ones in the Boom preset.
User avatar
PhysixCat
 
Joined: 15 Jan 2019

Re: [Solved] Crash on Hideous Destructor, GZDoom 4.1.3

Postby PhysixCat » Mon Jul 15, 2019 1:14 pm

https://github.com/MatthewTheGlutton/HideousDestructor/commit/98c9058e052d745cdbb27d074bb4da027ea8cfd1

I am happy to report that after Matt's latest commit, this crash no longer occurs even if compat_soundtarget = true. Weird edge-case resolved!

Also, I notified the author of Vanilla Essence (Pixel Eater) in their thread, in case this sort of thing affects anyone else down the road.
https://forum.zdoom.org/viewtopic.php?f=43&t=59412&start=60#p1111524
User avatar
PhysixCat
 
Joined: 15 Jan 2019

Previous

Return to Technical Issues

Who is online

Users browsing this forum: No registered users and 1 guest