[r918] Crash playing hexen

[Blue Shadow]

Hi,

Entering map 34(Wolf Chapel) crashes the game using gl renderer but it doesn't do that using the software renderer.

I'm only loading brightmaps and lights pk3s besides hexen wad.

[Gez]

It doesn't crash either without dynlights.

I've had the crash happen in a variety of places in the code, depending on whether textured automap were on and off, and on whether I went there directly from the menu or from within the level, and on whether I ran a debug or release build, and finally on apparently random chaos.

I got one heap corruption once, the rest of the time it was access violation related to subsectors and dynamic lights.

[Blue Shadow]

I tried the the map today with r923 and it works. I used the 'map' console command and
the portals that leads to it from other maps, no crashes upon entering.

[Gez]

Good for you, but the crash on MAP34 still happens to me.

I also got it with r880 (official 1.5.0 build).

[Blue Shadow]

Unfortunately, while I was playing that map, it crashed on me when I loaded the save file after I died. I thought it might be one of those crashes
that you can't repeat. So, I started the game, loaded the save then it crashed again and it kept on doing that every time I try.

The thing is that I don't know how I managed to enter the map the first time without GZDoom breaking itself or anything like that.

[Enjay]

Do you still have the savegame file? If so, posting it here may help.

[Gez]

So, 1.5.0 crashes and 1.4.8 works.

I've compiled intermediary builds.
r800, r842, r860, r870 all work.
r875 crashes.
r874 works without crashing.

Okay, so the root cause of crashes in Wolf Chapel involves dynamic lights and appeared with the polyobjects rewrite.

When running in the debugger, it doesn't always crash at the same place. The two most frequent places where it stops, however, are those:

p_map.cpp

Code: Select all

void P_DelSeclist (msecnode_t *node)
{
	while (node)
		node = P_DelSecnode (node);
}

and a_dynlight.cpp

Code: Select all

void ADynamicLight::CollectWithinRadius(subsector_t *subSec, float radius)
{
...
		if (partner)
		{
			subsector_t *sub = partner->Subsector();
			if (sub->validcount!=::validcount)
			{
				// check distance from x/y to seg and if within radius add opposing subsector (lather/rinse/repeat)
				if (DistToSeg(seg) <= radius)
				{
					CollectWithinRadius(sub, radius);
				}
			}
		}
	}
}

Guess what the debugger told me in the second case? The sub pointer's value is set to feeefeee. Magic word for freed heap memory.

It seems that some segs may have rubbish partner segs. The problem actually happens here:

Code: Select all

__forceinline subsector_t *	seg_t::Subsector() const
{
	return glsegextras[this - segs].Subsector;
}

For performances, it's inlined and there are no sanity checks there. But what happens when the "this" pointer has a lower value than the segs pointer? (Or a value greater than it by more than numsegs, for that matter.)

Debugging showed me values like for instance 0x4c0f5f0 for segs, 0x12f01c for partner, so CollectWithinRadius tempted to access glsegextra[-2453551]'s subsector...

For some reason, this happens in MAP34 nearly all the times (only once in all my tests with a post-r874 build did it not crash when dynamic lights were active), but doesn't seem to happen in others. There must be a very malformed polyobject or something like that which triggers such garbage values.

[Graf Zahl]

Grrrr...

Randy and his stupid code optimizations. I knew that this would inevitably cause trouble but unlike the subsector nonsense I had no good reason to revert this one in ZDoom.


MAP34 doesn't have a single polyobject, btw.

[Gez]

MAP40 has the same issue.

But what I don't get is how come any of the maps work? If I add some sanity checking at the end of P_CheckNodes() in p_glnodes.cpp, it tells me that all the segs have bad partners, for all maps.

[Graf Zahl]

Can you try to clear the node cache? I suspect you still got some old nodes from the broken node builder hanging around.

Type 'clearnodecache' in the console.

I think I'll have to add a check in the engine for that.

[Gez]

Cached nodes are not the issue: http://pastebin.com/QfcTtCwK

[Graf Zahl]

Can you also post the output of a 'dumpgeometry' CCMD for that map? That looks fine for me and I don't get any crashes on these maps so it's all a bit puzzling.

[Gez]

Here: http://pastebin.com/b9zc1vJp

[Graf Zahl]

Ugh. Nasty, nasty.

The nodes are fine. These levels just had a setup that made an actor call its SetState function before the level was fully initialized. And in this particular case it caused a dynamic light to change and try to link itself back into uninitialized subsectors...

I'll have to see what I can do here. This is not a trivial fix.

[Graf Zahl]

Hm, yeah, the only thing I could come up with was the brute force method and split the code up so that it gets initialized before the actors get spawned.