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

[Solved] Crash on Hideous Destructor, GZDoom 4.1.3

Post by PhysixCat »

I have found a way to reliably make GZDoom crash on my machine, with a specific interaction in the "Hideous Destructor" mod. However, I'm seemingly the only user (at least in the unofficial HD discord) who has reported having this particular crash, so I decided I'd use the debug version of GZD and run a backtrace to post here, in hopes someone can make heads or tails of it.

First things first - how I reproduce the crash on my end:
1. Start any map (the more corpses & enemies, the faster it should be to reproduce)
2. Type `summon archangel` into the console (friendly Archvile in Hideous Destructor)
3. Either wait a minute or so, or type `i_timescale 50` to speed things up
4. The ArchAngel will attack nearby enemies and resurrect corpses as allies
5. Sooner or later, on one of the resurrections of corpses as allies or during the presence of friendly resurrected demons, crash will occur:

Code: Select all

*** Fatal Error ***
Address not mapped to object (signal 11)
Address: 0x7ffc1a70afe8

System: Linux heim 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5 (2019-06-19) x86_64 GNU/Linux

GZDoom version g4.1.3 (d3e04a94c0fc4e4ab0480f69e25f1eefe9ed803a)
Compiler version: 8.3.0

Command line: /usr/games/gzdoom/gzdoom -iwad doom_complete.pk3 -file equinox.zip hideous_destructor

Wad 0: gzdoom.pk3
Wad 1: zd_extra.pk3
Wad 2: doom_complete.pk3
Wad 3: equinox.zip
Wad 4: equinox.zip:equinox.wad
Wad 5: 

Current map: map01

viewx = -416.482277
viewy = 3892.601535
viewz = 124.000000
viewangle = 159.479187

Executing: gdb --quiet --batch --command=gdb-respfile-AFs2uU
The crash also occurs through consuming blue magic (soulsphere, blue potions, etc), which in HD grants the player a chance to resurrect nearby corpses as allies, although it can take more time to reproduce because of RNG.

And now, this is the output on the crash from Debug GZDoom in gdb

Code: Select all

Thread 1 "gzdoom" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff513e900 (LWP 5976)]
0x0000555555b03b78 in xs_Fix<16>::ToFix (val=<error reading variable: Cannot access memory at address 0x7fffff7feff8>)
    at /home/ignacio/data/gzdoom_build/gzdoom/src/utility/xs_Float.h:91
91          finline static Fix       ToFix       (real64 val)   {return xs_ConvertToFixed(val);}
And this is the backtrace in gdb right after

Code: Select all

(gdb) backtrace
#0  0x0000555555b03b78 in xs_Fix<16>::ToFix (val=<error reading variable: Cannot access memory at address 0x7fffff7feff8>)
    at /home/ignacio/data/gzdoom_build/gzdoom/src/utility/xs_Float.h:91
#1  0x0000555555afb58e in FloatToFixed (f=351.30619505835591) at /home/ignacio/data/gzdoom_build/gzdoom/src/utility/m_fixed.h:99
#2  0x00005555561fece0 in FLevelLocals::PointInSubsector (this=0x555557504460 <level>, x=351.30619505835591, y=2773.2464121425264)
    at /home/ignacio/data/gzdoom_build/gzdoom/src/p_maputl.cpp:1953
#3  0x00005555561431c3 in FLevelLocals::PointInSector (this=0x555557504460 <level>, pos=...) at /home/ignacio/data/gzdoom_build/gzdoom/src/./g_levellocals.h:373
#4  0x00005555561e3451 in P_CheckPosition (thing=0x55555f4624f0, pos=..., tm=..., actorsonly=false) at /home/ignacio/data/gzdoom_build/gzdoom/src/p_map.cpp:1677
#5  0x00005555561e5390 in P_TryMove (thing=0x55555f4624f0, pos=..., dropoff=0, onfloor=0x0, tm=..., missileCheck=false)
    at /home/ignacio/data/gzdoom_build/gzdoom/src/p_map.cpp:2165
#6  0x00005555561bd4c0 in P_Move (actor=0x55555f4624f0) at /home/ignacio/data/gzdoom_build/gzdoom/src/p_enemy.cpp:523
#7  0x00005555561c21dd in A_Wander (self=0x55555f4624f0, flags=0) at /home/ignacio/data/gzdoom_build/gzdoom/src/p_enemy.cpp:2124
#8  0x00007ffff2a24435 in ?? ()
#9  0x00007fffff7ffbf0 in ?? ()
#10 0x00005555561fb688 in FBlockLinesIterator::StartBlock (this=0x8000000000000001, x=1206910975, y=-536870912)
    at /home/ignacio/data/gzdoom_build/gzdoom/src/p_maputl.cpp:633
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
If any more information is needed, I'll be happy to provide it
Last edited by PhysixCat on Mon Jul 15, 2019 9:51 am, edited 1 time in total.
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
Contact:

Re: Crash on Hideous Destructor, GZDoom 4.1.3

Post by Matt »

Just want to add that I have not been able to replicate this crash at all on my end, though it seems pretty consistent for PhysixCat.

I haven't gotten any other reports either so this might be a "Technical Issue" rather than a "GZDoom bug".
_mental_
 
 
Posts: 3812
Joined: Sun Aug 07, 2011 4:32 am

Re: Crash on Hideous Destructor, GZDoom 4.1.3

Post by _mental_ »

You can try to run GZDoom with JIT disabled by adding +vm_jit 0 command line option.
If it still crashes, create core dump in GDB with gcore gzdoom.dmp command, pack gzdoom (executable) and gzdoom.dmp, and upload somewhere.
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 »

_mental_ wrote:You can try to run GZDoom with JIT disabled by adding +vm_jit 0 command line option.
If it still crashes, create core dump in GDB with gcore gzdoom.dmp command, pack gzdoom (executable) and gzdoom.dmp, and upload somewhere.
I tried running GZDoom with JIT disabled, and did a test run on E1M3; it still crashed.

However, I noticed something that might also be of interest - in one instance, it crashed with a SIGSEGV and a huge backtrace. In the other, it crashed with SIGABRT and a small backtrace. These two were both from the same crash I'm talking about, with the same type of test.

Here are both uploaded packages, as requested. They also include their debug logs - just in case.
SIGABRT crash info: https://mega.nz/#!akkGGQYK!S9VAmAUpdJfm ... zaal-Km9Io
SIGSEGV crash info: https://mega.nz/#!6ktGgaoC!Cffk-pIMEzOS ... 23X-Dt8zZE
_mental_
 
 
Posts: 3812
Joined: Sun Aug 07, 2011 4:32 am

Re: Crash on Hideous Destructor, GZDoom 4.1.3

Post by _mental_ »

The first dump is an assertion failure inside the engine. The function was LevelLocals.isFrozen called from BarrelExplodeMarker.Tick. With JIT disabled LevelLocals.isFrozen() was broken indeed.

The second one is stack overflow because of infinite recursion. Callstack is something like this (can be incomplete). Matt should take a look into this one.

Code: Select all

Actor.A_ClearTarget
HDMobAI.chase
hdmarine.StateFunction.24
HDMobAI.Wander
Actor.A_Look
hdmarine.StateFunction.1
Actor.SetStateLabel
HDMobAI.chase
hdmarine.StateFunction.24
HDMobAI.Wander
...
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
Contact:

Re: Crash on Hideous Destructor, GZDoom 4.1.3

Post by Matt »

.....

Assuming A_Chase will just abort to spawn if there's no target, I really can't see how the code as it's currently written could lead to an infinite loop.

That code is long overdue for a total overhaul anyway though.
_mental_
 
 
Posts: 3812
Joined: Sun Aug 07, 2011 4:32 am

Re: Crash on Hideous Destructor, GZDoom 4.1.3

Post by _mental_ »

No point to keep this open as there no way to fix infinite loops/recursions from the engine side.
Of course, a more graceful handling like VM abort would be great. Although, it's completely different topic.
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 »

_mental_ wrote:No point to keep this open as there no way to fix infinite loops/recursions from the engine side.
Of course, a more graceful handling like VM abort would be great. Although, it's completely different topic.
Before this is fully closed, may I upload a few more crash dumps, just to confirm the cause is always infinite recursion?
_mental_
 
 
Posts: 3812
Joined: Sun Aug 07, 2011 4:32 am

Re: Crash on Hideous Destructor, GZDoom 4.1.3

Post by _mental_ »

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

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

(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)
_mental_
 
 
Posts: 3812
Joined: Sun Aug 07, 2011 4:32 am

Re: Crash on Hideous Destructor, GZDoom 4.1.3

Post by _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.
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 »

_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
_mental_
 
 
Posts: 3812
Joined: Sun Aug 07, 2011 4:32 am

Re: Crash on Hideous Destructor, GZDoom 4.1.3

Post by _mental_ »

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

Re: Crash on Hideous Destructor, GZDoom 4.1.3

Post by Graf Zahl »

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

Return to “Technical Issues”