Welcome to the ZDoom Forums!

[url]https://github.com/MatthewTheGlutton/HideousDestructor/commit/98c9058e052d745cdbb27d074bb4da027ea8cfd1[/url]

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.
[url]https://forum.zdoom.org/viewtopic.php?f=43&t=59412&start=60#p1111524[/url]

[quote]The one responsible here should be compat_soundtarget.[/quote]

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.

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

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 [url]https://forum.zdoom.org/viewtopic.php?t=59412[/url] (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.

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

HDMobAI.chase
fighterimp.A_ImpChase
fighterimp.StateFunction.25
Actor.A_Look
Actor.SetState
Actor.SetStateLabel
HDMobAI.chase
fighterimp.A_ImpChase
fighterimp.StateFunction.25
...

If callstack contains ~20k entries, it's infinite recursion for sure.
[code]HDMobAI.chase
fighterimp.A_ImpChase
fighterimp.StateFunction.25
Actor.A_Look
Actor.SetState
Actor.SetStateLabel
HDMobAI.chase
fighterimp.A_ImpChase
fighterimp.StateFunction.25
...[/code]

Matt recently added a check to [b]HDMobAI.Chase[/b] to the master branch of Hideous Destructor
[url]https://github.com/MatthewTheGlutton/HideousDestructor/commit/e67db26c67387705b2b008567a634f8912bc3269[/url],
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_qPDA4NsFxM6QS-dRfGcsDK1cpNjr6Qw92-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)

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?

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.

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

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]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
...[/code]
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.

[quote="_mental_"]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.[/quote]

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: [url]https://mega.nz/#!3t0FEASA!bnyVQObuUwBpxB-4YBgffkiSoM3z_9qRwzoG2KU8aNw[/url]
Zip8: [url]https://mega.nz/#!bxkDnaCS!9dZSAaXlF3Ko1_RtfzF1Ink1Zf1S0FJhvs3-giF3Jw8[/url]
Zip9: [url]https://mega.nz/#!u1tRAAJT!3sRmnj65DY_coYqlboE7MOSzJNCzAfREZGDyU53QuK0[/url]
Zip10: [url]https://mega.nz/#!25lHgYwB!d7t_C7-85WCTDp_PodsHWJ0Ntq0he7slykQUlTdTNII[/url]

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.

(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)

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__LVvMFhV8HHgKbP6fJ43Wk4e0sNTsFwouFjUw
Zip 4: https://mega.nz/#!H9cVUIpB!9KDnmJI9VXApRQfjxZS3Ter4XZFXNCbQPJOT7nvICWk
Zip 5: https://mega.nz/#!ekFnFabS!ctERc1bXeGUsGwrzpOcJNhsNeQXDAvjbxiIL3nR4SOU
Zip 6: https://mega.nz/#!LlFl1KLY!DteD21PZ8ViSZmKIr_pK3-AMIRK3JM3ahGL0q6Fy4rY

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.

Sure.