[Fixed] [GZDoom] Crash while shooting through a ceiling/floor portal

Bugs that have been investigated and resolved somehow.

Moderator: Developers

[GZDoom] Crash while shooting through a ceiling/floor portal

Postby Shrinker » Mon Oct 16, 2017 1:12 pm

(My first time trying to submit this thread didn't work. If there is a duplicate (as a guest poster?), please discard the other thread).
Hello,
the wad file used here is from me, it's [wad redacted, new file in next post].
I am using brutalv20b_R.pk3 as a pwad on top of doom2 as an iwad.
The MAP01 in the wad contains a room with two stories built using a ceiling/floor portal. The crash can be provoked by running around on the lower floor with a chaingun and shooting upwards into the other floor, between the columns. I've also observed this crash in a room with simpler geometry, i.e. without those decorative columns in between. I suspect it could be an edge case where particles or projectile rays or whatever make the transition through the portal as I just cross sector boundaries.
I've started the map via GZDoomBuilder Bugfix.
Thanks for your effort!
Regards, Shrinker

[crash zip redacted, new file in next post]
Last edited by Shrinker on Thu Oct 19, 2017 3:12 pm, edited 2 times in total.
User avatar
Shrinker
 
Joined: 16 Oct 2017

Re: Crash while shooting through a ceiling/floor portal

Postby Shrinker » Wed Oct 18, 2017 9:30 am

Good news! I've got a better repro now that's 100% reliable on my system.
Attached is a wad file with two very simple rooms above each other.
You stand in the lower room and look at a burning barrel in the upper room.
Using your Brutal Doom assault rifle, the game crashes very quickly as soon as you fire a few shots at the thin ledge facing you, directly under the barrel - sometimes even already on the first shot. There is probably a specific raycast angle that triggers this, and it has a good chance to be hit with the bullet spread on continuous fire.
This does not happen with the regular Doom 2 chaingun.
My settings have it that the Brutal Doom bullet impacts come with particles and dynamic light effects.
Disabling the dynamic light effects made no difference: The crash persists even without them.
Attachments
repro.wad
The wad file
(7.26 KiB) Downloaded 15 times
CrashReport.zip
A recorded crash - this time after a few bullets
(21.73 KiB) Downloaded 9 times
User avatar
Shrinker
 
Joined: 16 Oct 2017

Re: [GZDoom] Crash while shooting through a ceiling/floor po

Postby Shrinker » Tue Dec 19, 2017 11:55 am

I can confirm that this crash is still present in GZDoom 3.2.4 (32bit).
User avatar
Shrinker
 
Joined: 16 Oct 2017

Re: [GZDoom] Crash while shooting through a ceiling/floor po

Postby Shrinker » Sat Jan 06, 2018 3:30 pm

Happy new year!
Okay, so I've installed the current edition of Visual Studio and CMake and got it running and reproduced the bug with the debugger enabled!

I present: My more detailed bug report :D
This is for version 3.2.4.
Proposed fix: See at the end of the post.

From top to bottom, this is where the crash comes from:
g_levellocals.h:
Code: Select allExpand view
   inline int sector_t::GetOppositePortalGroup(int plane)
      return level.sectorPortals[Portals[plane]].mDestination->PortalGroup;
      Unhandled exception thrown: read access violation.
      TArray<FSectorPortal,FSectorPortal>::operator[](...).mDestination was nullptr.


level.sectorPortals[Portals[plane]].mDestination is nullptr, so ->PortalGroup crashes it.

The .sectorPortals seem to indicate those actual portals from the feature that you can see and move through portals (struct FSectorPortal in portal.h).
Code: Select allExpand view
unsigned Portals[2]; per sector_t are indexes into that array, reading "// [RH] The portal or skybox to render for this sector."

Portals[0] and Portals[1] are both 0 here.

Coming from:
p_map.cpp
Code: Select allExpand view
// P_TryMove
// Attempt to move to a new position,
// crossing special lines unless MF_TELEPORT is set.
bool P_TryMove(AActor *thing, ...


Code: Select allExpand view
// If the actor stepped through a ceiling portal we need to reacquire the actual position info after the transition
if (tm.portalstep)
{
   FLinkContext ctx;
   DVector3 oldpos = thing->Pos();
   thing->UnlinkFromWorld(&ctx);
   thing->SetXYZ(thing->PosRelative(thing->Sector->GetOppositePortalGroup(sector_t::ceiling)));

^ setXYZ

Call from p_mobj.cpp/double P_XYMovement (AActor *mo, DVector2 scroll)

I dunno what kind of actor this is. Maybe a puff of smoke or a spark so. At first glance it looks like it crashes the moment this thing rises through the portal upward.

Does the sector have wrong information, or is thing->Sector wrong in that moment?
Map layout:
Code: Select allExpand view
   bottom inner tag 1, sector id 2
   bottom outer tag 0, sector id 3
   top inner tag 3, sector id 0
   top outer tag 0, sector id 1
   The ceiling of bottom inner is the floor of top inner.


Inspecting level.sectors:
Code: Select allExpand view
   0 (top    inner): Portals = {3, 0}
   1 (top    outer): Portals = {0, 0}
   2 (bottom inner): Portals = {0, 2}
   3 (bottom outer): Portals = {0, 0}


thing->Sector in setXYZ points at sector 3 in my crash moment, the bottom outer, while I think it should point at 2, the bottom inner then.
Hm... so maybe the thing moved parallel to the world floor, but also vertically - Maybe at the ledge, it moves diagonally?
Could "if (tm.portalstep)" in p_map.cpp yield true while at the same time the thing moves out of the sector?
In P_TryMove, there's *oldsector and also *oldsec, and both point at sector 2 in that moment, which would be correct.

============================

My theory:
in p_map.cpp, replacing thing->Sector with oldsector in
Code: Select allExpand view
thing->SetXYZ(thing->PosRelative(thing->Sector->GetOppositePortalGroup(sector_t::ceiling)));

should do the trick, at least with my limited understanding of what I see there (could also be that the other "old" variable is supposed to be used).
After all, there is also a reference to "oldpos" in the next line of code.

Making that little change and compiling it, the game stopped crashing for me in my test case. :D

Could someone please check that out? Hoping that the next release doesn't have this crash bug anymore then. :)
This was a fun little endeavor!
User avatar
Shrinker
 
Joined: 16 Oct 2017

Re: [GZDoom] Crash while shooting through a ceiling/floor po

Postby Shrinker » Fri Jan 19, 2018 7:14 am

Any way I can assist further in fixing this? My solution worked fine for me. :)
User avatar
Shrinker
 
Joined: 16 Oct 2017

Re: [GZDoom] Crash while shooting through a ceiling/floor po

Postby _mental_ » Fri Jan 19, 2018 7:45 am

If somebody had something to answer (i.e. someone who has an idea what's actually wrong AND who has time to check) then he/she would post a reply.
Personally I have no idea so I didn't post anything. This is not the first unresolved issue with portals I checked but couldn't do anything with it.
_mental_
 
 
 
Joined: 07 Aug 2011

Re: [GZDoom] Crash while shooting through a ceiling/floor po

Postby Shrinker » Sat Jan 27, 2018 4:57 am

The one-line code change worked fine for me with no further crashes at all. I can imagine checking and fixing that function with this info would take only a few minutes.
If I knew of another portal-related crash, I'd try to figure it out in the same manner. The code looked pretty solid. :)
User avatar
Shrinker
 
Joined: 16 Oct 2017

Re: [GZDoom] Crash while shooting through a ceiling/floor po

Postby _mental_ » Sat Jan 27, 2018 5:25 am

Shrinker wrote:The one-line code change worked fine for me with no further crashes at all. I can imagine checking and fixing that function with this info would take only a few minutes.

If some change works in your test case this doesn't make it correct automatically.
There is absolutely no relation between number of changed lines and their correctness.
And usually there is no relation between number of changed lines and simplicity of their verification either.

If you are so confident in the fix then make a pull request and ask Graf to review it.

Shrinker wrote:If I knew of another portal-related crash, I'd try to figure it out in the same manner. The code looked pretty solid. :)

This is just great that someone finds portal code obvious :thumb: If so, you will probably fix this and this with ease.
_mental_
 
 
 
Joined: 07 Aug 2011

Re: [GZDoom] Crash while shooting through a ceiling/floor po

Postby Shrinker » Sun Jan 28, 2018 5:09 pm

_mental_ wrote:If you are so confident in the fix then make a pull request and ask Graf to review it.

Could you walk me through where to register and which repository to target? :)
I can have a really good look again at the one ambiguity I found (which "old" variable to use) and then submit that request/code change suggestion.
As for the other two crashes, I shall have a look.
User avatar
Shrinker
 
Joined: 16 Oct 2017


Re: [GZDoom] Crash while shooting through a ceiling/floor po

Postby Shrinker » Mon Jan 29, 2018 9:52 am

I've registered to Github and managed to create a pull request for review. :D
https://github.com/coelckers/gzdoom/pull/418
Never used Github before... seems quite nice.
Cheers. :)
User avatar
Shrinker
 
Joined: 16 Oct 2017

Re: [GZDoom] Crash while shooting through a ceiling/floor po

Postby Graf Zahl » Wed Feb 28, 2018 3:49 am

I think there's an even better way to address this, by using the actual portal group that was retrieved when the step through the portal was determined.
I will have to run a few tests, though, that this is the correct one to pick, but what I have seen indicates that this is what we want - and more importantly, has no risk of causing a crash due to a portal-less sector getting in the way.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: [GZDoom] Crash while shooting through a ceiling/floor po

Postby Graf Zahl » Wed Feb 28, 2018 4:17 am

I think the problems leading to the crash are all addressed now. Firing a projectile at that ledge now produces the expected result, i.e. the projectile explodes in front of the wall not on top of ot. The interpolation issue present here is also fixed now.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany


Return to Closed Bugs

Who is online

Users browsing this forum: No registered users and 0 guests