[Solved] Crash on Hideous Destructor, GZDoom 4.1.3

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

Moderator: GZDoom Developers

Forum rules
Contrary to popular belief, we are not all-knowing-all-seeing magical beings!

If you want help you're going to have to provide lots of info. Like what is your hardware, what is your operating system, what version of GZDoom/LZDoom/whatever you're using, what mods you're loading, how you're loading it, what you've already tried for fixing the problem, and anything else that is even remotely relevant to the problem.

We can't magically figure out what it is if you're going to be vague, and if we feel like you're just wasting our time with guessing games we will act like that's what you're really doing and won't help you.
User avatar
Matt
Posts: 9696
Joined: Sun Jan 04, 2004 5:37 pm
Preferred Pronouns: They/Them
Operating System Version (Optional): Debian Bullseye
Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia

Re: Crash on Hideous Destructor, GZDoom 4.1.3

Post by Matt »

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
PhysixCat
Posts: 43
Joined: Tue Jan 15, 2019 11:14 am

Re: Crash on Hideous Destructor, GZDoom 4.1.3

Post by PhysixCat »

Matt recently added a check to HDMobAI.Chase to the master branch of Hideous Destructor
https://github.com/MatthewTheGlutton/Hi ... 8912bc3269,
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)
_mental_
 
 
Posts: 3814
Joined: Sun Aug 07, 2011 4:32 am

Re: Crash on Hideous Destructor, GZDoom 4.1.3

Post by _mental_ »

If callstack contains ~20k entries, it's infinite recursion for sure.

Code: Select all

HDMobAI.chase
fighterimp.A_ImpChase
fighterimp.StateFunction.25
Actor.A_Look
Actor.SetState
Actor.SetStateLabel
HDMobAI.chase
fighterimp.A_ImpChase
fighterimp.StateFunction.25
...
User avatar
Matt
Posts: 9696
Joined: Sun Jan 04, 2004 5:37 pm
Preferred Pronouns: They/Them
Operating System Version (Optional): Debian Bullseye
Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia

Re: Crash on Hideous Destructor, GZDoom 4.1.3

Post by Matt »

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
PhysixCat
Posts: 43
Joined: Tue Jan 15, 2019 11:14 am

Re: Crash on Hideous Destructor, GZDoom 4.1.3

Post by PhysixCat »

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 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
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49098
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Crash on Hideous Destructor, GZDoom 4.1.3

Post by Graf Zahl »

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
PhysixCat
Posts: 43
Joined: Tue Jan 15, 2019 11:14 am

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

Post by PhysixCat »

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
Posts: 43
Joined: Tue Jan 15, 2019 11:14 am

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

Post by PhysixCat »

https://github.com/MatthewTheGlutton/Hi ... 027ea8cfd1

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.
viewtopic.php?f=43&t=59412&start=60#p1111524

Return to “Technical Issues”