[Solved] Crash on Hideous Destructor, GZDoom 4.1.3

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.

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies

BBCode is OFF
Smilies are ON

Topic review
   

Expand view Topic review: [Solved] Crash on Hideous Destructor, GZDoom 4.1.3

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

by PhysixCat » Mon Jul 15, 2019 12:14 pm

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

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

by PhysixCat » Mon Jul 15, 2019 10: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.

Re: Crash on Hideous Destructor, GZDoom 4.1.3

by Graf Zahl » Mon Jul 15, 2019 3: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.)

Re: Crash on Hideous Destructor, GZDoom 4.1.3

by PhysixCat » Mon Jul 15, 2019 1: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 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.

Re: Crash on Hideous Destructor, GZDoom 4.1.3

by Matt » Sun Jul 14, 2019 4: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).

Re: Crash on Hideous Destructor, GZDoom 4.1.3

by _mental_ » Sun Jul 14, 2019 1:47 am

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
...

Re: Crash on Hideous Destructor, GZDoom 4.1.3

by PhysixCat » Sat Jul 13, 2019 12:22 pm

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)

Re: Crash on Hideous Destructor, GZDoom 4.1.3

by Matt » Fri Jul 12, 2019 1: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?

Re: Crash on Hideous Destructor, GZDoom 4.1.3

by Graf Zahl » Fri Jul 12, 2019 1:47 am

This looks like it calls A_Look from an inappropriate place. Note: This function may not be called from code that performs AI when the monster has a target. It will immediately jump to the 'See' state, and if that by any chance calls anything calling A_Look again you'll end up with a recursion problem.

Re: Crash on Hideous Destructor, GZDoom 4.1.3

by _mental_ » Fri Jul 12, 2019 1:36 am

All these crashes are caused by stack overflow as the result of infinite recursion. Script callstacks are either the following or the one I already posted before

Code: Select all

Actor.A_ClearTarget
HDMobAI.chase
HideousShotgunGuy.StateFunction.26
Actor.A_Look
HideousShotgunGuy.StateFunction.2
Actor.SetStateLabel
HDMobAI.chase
HideousShotgunGuy.StateFunction.26
Actor.A_Look
HideousShotgunGuy.StateFunction.2
Actor.SetStateLabel
HDMobAI.chase
...
I have no idea why no one else encountered this issue. Probably, it's because of your HD settings.
As it has bunch of CVARs to configure its behavior, you need to give your config file to Matt along with steps to reproduce.

Re: Crash on Hideous Destructor, GZDoom 4.1.3

by PhysixCat » Thu Jul 11, 2019 8:36 pm

_mental_ wrote:With JIT enabled GDB cannot reconstruct callstacks properly. There is no way to tell exactly what happened.
In case of stack overflow the game can crash pretty much everywhere. A few frames from the top of the stack are not enough to make any conclusions.
My bad, sorry. The following 4 crash samples were taken with JIT disabled. All of them were SIGSEGV. Can any further clues/conclusions be drawn from them? I'm just puzzled as to why I'm seemingly the only Hideous Destructor player that's getting these. :?

Zip7: https://mega.nz/#!3t0FEASA!bnyVQObuUwBp ... zoG2KU8aNw
Zip8: https://mega.nz/#!bxkDnaCS!9dZSAaXlF3Ko ... s3-giF3Jw8
Zip9: https://mega.nz/#!u1tRAAJT!3sRmnj65DY_c ... GDyU53QuK0
Zip10: https://mega.nz/#!25lHgYwB!d7t_C7-85WCT ... kQUlTdTNII

Re: Crash on Hideous Destructor, GZDoom 4.1.3

by _mental_ » Thu Jul 11, 2019 1:58 am

With JIT enabled GDB cannot reconstruct callstacks properly. There is no way to tell exactly what happened.
In case of stack overflow the game can crash pretty much everywhere. A few frames from the top of the stack are not enough to make any conclusions.

Re: Crash on Hideous Destructor, GZDoom 4.1.3

by PhysixCat » Wed Jul 10, 2019 3:56 pm

(Just to clarify, I meant that I've posted those zips above because I'd like for someone knowledgeable to check if indeed the cause is consistently stack overflow because of infinite recursion. I don't know if this is actually the case)

Re: Crash on Hideous Destructor, GZDoom 4.1.3

by PhysixCat » Tue Jul 09, 2019 2:26 pm

Okay, here they come. All were taken by the entrance of E1M3. Just summoned an archangel and waited, watching the fight.

Zip 3: https://mega.nz/#!6hVhGCYa!cyYjU__LVvMF ... TsFwouFjUw
Zip 4: https://mega.nz/#!H9cVUIpB!9KDnmJI9VXAp ... JOT7nvICWk
Zip 5: https://mega.nz/#!ekFnFabS!ctERc1bXeGUs ... iIL3nR4SOU
Zip 6: https://mega.nz/#!LlFl1KLY!DteD21PZ8ViS ... GL0q6Fy4rY

To my untrained eye at least, it seemed like they had the SIGSEGV at different parts of the code, but I don't know if that's relevant.

Top