DRD Team

Posted: **Wed Oct 12, 2011 22:55**

Yeah, you know, the megawad with the tiny 64x64 maps. To replicate the crash, make sure you are loading dynamic lights.

As far as I can tell, the problem is caused by this chain of events:

When the player is spawned in vanilla, the pawn telefrags monsters. Whenever a monster is met in Congestion 64, the bounding boxes overlap. Normally the level design is cramped enough that you don't realize that you're stuck until you've disposed of the monster anyway; but in ZDoom the monsters are just killed instantly.
On MAP20, the monster of the level is a lost soul. Lost souls have a dynamic light attached to them.
Dying updates the dynamic light, and makes the crash happens. On an earlier level, there is a barrel, which also has a dynamic light attached, but it does not have its state changed in the very first gametic and nothing bad happens.

The crash happens within ADynamicLight::CollectWithinRadius(). Specifically here:

Code: Select all

		seg_t *partner = seg->PartnerSeg;
		if (partner)
		{
			subsector_t *sub = partner->Subsector;
			if (sub != NULL && sub->validcount!=::validcount)

In my tests, the value of partner was consistently 0xC8, though I guess it might change on another computer. Regardless, it is non-NULL yet clearly far too low to be a valid pointer to the program's allocated memory.

Looking into it, it seems partner segs are initialized in gl_PreprocessLevel(). However, CollectWithinRadius() can be called before the level is preprocessed, for example through this chain: P_SpawnThings -> SpawnMapThing -> P_SpawnMapThing -> AActor::StaticSpawn -> FGLInterface::StateChanged -> gl_SetActorLights -> gl_AttachLight -> FLightDefaults::ApplyProperties -> ADynamicLight::SetOffset -> ADynamicLight::UpdateLocation -> ADynamicLight::LinkLight -> ADynamicLight::CollectWithinRadius

Since P_SetupLevel calls P_SpawnThings before it calls Renderer->PreprocessLevel, this might be the chain of function calls responsible for the crash. I haven't debugged the trace thoroughly yet so I'm not sure it's the path taken to the crash, but it seems possible.

I'll look more into it tomorrow.

Posted: **Thu Oct 13, 2011 7:55**

I testd it on two builds, the latest and r1231, and strangely it didn't crash on me

. Is this why?

Gez wrote:In my tests, the value of partner was consistently 0xC8, though I guess it might change on another computer.

Posted: **Thu Oct 13, 2011 14:16**

Okay, so I've placed the preprocess call before map things are spawned, as so:

Code: Select all

	bodyqueslot = 0;
// phares 8/10/98: Clear body queue so the corpses from previous games are
// not assumed to be from this one.

	for (i = 0; i < BODYQUESIZE; i++)
		bodyque[i] = NULL;

	deathmatchstarts.Clear ();

	// This must be done BEFORE the PolyObj Spawn!!!
	Renderer->PreprocessLevel();

	if (!buildmap)
	{
		// [RH] Spawn slope creating things first.
		P_SpawnSlopeMakers (&MapThingsConverted[0], &MapThingsConverted[MapThingsConverted.Size()]);
		P_CopySlopes();

		// Spawn 3d floors - must be done before spawning things so it can't be done in P_SpawnSpecials
		P_Spawn3DFloors();

Is there anything that it may break? It didn't seem so in my few tests, but I'd be deluding myself if I thought they could remotely account for all possible quirks and circumstances that may happen. (This very thread is a case in point.)

Posted: **Thu Oct 13, 2011 22:10**

Okay, so found one thing that's broken by that fix: portals. For example, the hanging crate at the entrance KDiZD's Z1M1 gets a HOM above it; whereas without the change in order it's perfectly fine. If stack things haven't been handled yet, and neither have line specials, then the preprocessing won't be correct for portals.

Posted: **Thu Oct 13, 2011 22:42**

[stupid]Could you disable "telefragging" during the first gametic?[/stupid]

Posted: **Fri Oct 14, 2011 0:03**

The PreprocessLevel can't be moved. Don't even try.

Posted: **Fri Oct 14, 2011 13:12**

Then what? Could just the PrepareSegs() function be called before map things are spawned, and the rest of PreprocessLevel after? It'd solve the issue as well and it doesn't break the KDiZD portal.

Posted: **Fri Oct 14, 2011 22:33**

Why not fix the actual problem: Telefragging in the spawn code must be delayed until after the level is completely set up. I have had problems with that before but it seems I didn't fully fix them.

Posted: **Sat Dec 24, 2011 21:18**

When warping to Hexen's Map40 (whether by command line or console), I get a crash. Started removing autoloads until it stopped, which brought me to Lights.pk3. (I have lights disabled, usually, but kept the file loaded in case I'd want it. With them on or off, GZDoom still crashes with the file loaded.)

Ran it with only Lights.pk3 (loaded by command line) and got this crash. Report is attached.

(ZDoom doesn't crash, possibly because it ignores GLDEFS &c.)

Posted: **Sat Dec 24, 2011 22:26**

Yes, on warping to map40, it crashed for me too with only lights.pk3 loaded.

[edit] I wonder what it is about map40 that triggers this. I just warped through all the maps in the IWAD and only map40 caused a crash. [/edit]

Posted: **Sun Dec 25, 2011 1:47**

I warped to Map35 to see if it would be fine to play into the final map. It didn't.

But... I extracted hexndefs.txt and loaded it up, removing one section at a time until the crashing ceased. Tracked it down to this section:

Code: Select all

// Large flame
flickerlight2 LARGEFLAME
{
    color 1.0 0.7 0.0
    size 40
    secondarySize 48
    interval 0.1
}

object FlameLarge
{
    frame FFLG { light LARGEFLAME }
}

object FlameLargeTemp
{
    frame FFLG { light LARGEFLAME }
}

Specifically, if I remove the FlameLarge object binding, the crashing ceases.

Weirdness...

Posted: **Sun Dec 25, 2011 12:42**

NeuralStunner wrote:Weirdness...

Indeed.

I tried both summoning and placing the flame objects you listed into map01 and no crash. Yet warp to map40 and crash.

Posted: **Mon Dec 26, 2011 12:23**

Might be related to this.

Posted: **Mon Dec 26, 2011 19:35**

Gez wrote:Might be related to this.

There are indeed a lot of overlapping flames on the map. They shouldn't be telefragging one another, though.

"Heh Doom."

Posted: **Mon Dec 26, 2011 22:46**

Well, I tried a few things. Not sure if any of this will help.

Removing all the large flames from the map stops the crash.

Moving all the large flames so that there was a lot of space between each one did not stop the crash.

Re-saving the map as MAP01 did not stop the crash (when warping to map01 in this case).

Removing all the scripts from the map did not stop the crash.

Redefining the LARGEFLAME dynamic light as a flickerlight (as opposed to flickerlight2) did not stop the crash.

Redefining the LARGEFLAME dynamic light as a pointlight did stop the crash.

Code: Select all

pointlight LARGEFLAME
{
    color 1.0 0.7 0.0
    size 56
}

DRD Team

Crash on startup in Congestion 64 MAP20, Hexen MAP40, etc.

Crash on startup in Congestion 64 MAP20, Hexen MAP40, etc.

Re: Crash on startup in Congestion 64 MAP20

Re: Crash on startup in Congestion 64 MAP20

Re: Crash on startup in Congestion 64 MAP20

Re: Crash on startup in Congestion 64 MAP20

Re: Crash on startup in Congestion 64 MAP20

Re: Crash on startup in Congestion 64 MAP20

Re: Crash on startup in Congestion 64 MAP20

[r1280] Crash Warping to Hexen Map40 with Lights.pk3

Re: [r1280] Crash Warping to Hexen Map40 with Lights.pk3

Re: [r1280] Crash Warping to Hexen Map40 with Lights.pk3

Re: [r1280] Crash Warping to Hexen Map40 with Lights.pk3

Re: [r1280] Crash Warping to Hexen Map40 with Lights.pk3

Re: [r1280] Crash Warping to Hexen Map40 with Lights.pk3

Re: [r1280] Crash Warping to Hexen Map40 with Lights.pk3