[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

[Solved] Crash on Hideous Destructor, GZDoom 4.1.3

Postby PhysixCat » Fri Jul 05, 2019 3:02 pm

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 allExpand view
*** 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 allExpand view
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 allExpand view
(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 10:51 am, edited 1 time in total.
User avatar
PhysixCat
 
Joined: 15 Jan 2019

Re: Crash on Hideous Destructor, GZDoom 4.1.3

Postby Matt » Fri Jul 05, 2019 3:17 pm

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".
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 _mental_ » Sat Jul 06, 2019 3:02 am

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.
_mental_
 
 
 
Joined: 07 Aug 2011

Re: Crash on Hideous Destructor, GZDoom 4.1.3

Postby PhysixCat » Sat Jul 06, 2019 3:35 pm

_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!S9VAmAUpdJfmMKE20sjlkNqQijORTGaVBzaal-Km9Io
SIGSEGV crash info: https://mega.nz/#!6ktGgaoC!Cffk-pIMEzOS_AevzcAwSMyR-LUmzKqdS23X-Dt8zZE
User avatar
PhysixCat
 
Joined: 15 Jan 2019

Re: Crash on Hideous Destructor, GZDoom 4.1.3

Postby _mental_ » Sun Jul 07, 2019 3:10 am

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 allExpand view
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
...
_mental_
 
 
 
Joined: 07 Aug 2011

Re: Crash on Hideous Destructor, GZDoom 4.1.3

Postby Matt » Sun Jul 07, 2019 10:11 pm

.....

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.
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 _mental_ » Tue Jul 09, 2019 2:38 pm

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.
_mental_
 
 
 
Joined: 07 Aug 2011

Re: Crash on Hideous Destructor, GZDoom 4.1.3

Postby PhysixCat » Tue Jul 09, 2019 2:51 pm

_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?
User avatar
PhysixCat
 
Joined: 15 Jan 2019

Re: Crash on Hideous Destructor, GZDoom 4.1.3

Postby _mental_ » Tue Jul 09, 2019 3:00 pm

Sure.
_mental_
 
 
 
Joined: 07 Aug 2011

Re: Crash on Hideous Destructor, GZDoom 4.1.3

Postby PhysixCat » Tue Jul 09, 2019 3: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.
User avatar
PhysixCat
 
Joined: 15 Jan 2019

Re: Crash on Hideous Destructor, GZDoom 4.1.3

Postby PhysixCat » Wed Jul 10, 2019 4: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)
User avatar
PhysixCat
 
Joined: 15 Jan 2019

Re: Crash on Hideous Destructor, GZDoom 4.1.3

Postby _mental_ » Thu Jul 11, 2019 2: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.
_mental_
 
 
 
Joined: 07 Aug 2011

Re: Crash on Hideous Destructor, GZDoom 4.1.3

Postby PhysixCat » Thu Jul 11, 2019 9: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!bnyVQObuUwBpxB-4YBgffkiSoM3z_9qRwzoG2KU8aNw
Zip8: https://mega.nz/#!bxkDnaCS!9dZSAaXlF3Ko1_RtfzF1Ink1Zf1S0FJhvs3-giF3Jw8
Zip9: https://mega.nz/#!u1tRAAJT!3sRmnj65DY_coYqlboE7MOSzJNCzAfREZGDyU53QuK0
Zip10: https://mega.nz/#!25lHgYwB!d7t_C7-85WCTDp_PodsHWJ0Ntq0he7slykQUlTdTNII
User avatar
PhysixCat
 
Joined: 15 Jan 2019

Re: Crash on Hideous Destructor, GZDoom 4.1.3

Postby _mental_ » Fri Jul 12, 2019 2: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 allExpand view
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.
_mental_
 
 
 
Joined: 07 Aug 2011

Re: Crash on Hideous Destructor, GZDoom 4.1.3

Postby Graf Zahl » Fri Jul 12, 2019 2: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.
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Next

Return to Technical Issues

Who is online

Users browsing this forum: No registered users and 0 guests