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

Bugs that have been resolved.

Moderator: Graf Zahl

User avatar
Gez
Developer
Developer
Posts: 1391
Joined: Mon Oct 22, 2007 16:47

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

Post by Gez » 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.
Last edited by Gez on Tue Dec 27, 2011 15:44, edited 1 time in total.

User avatar
Blue Shadow
Global Moderator
Global Moderator
Posts: 302
Joined: Sun Aug 29, 2010 6:09

Re: Crash on startup in Congestion 64 MAP20

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

User avatar
Gez
Developer
Developer
Posts: 1391
Joined: Mon Oct 22, 2007 16:47

Re: Crash on startup in Congestion 64 MAP20

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

User avatar
Gez
Developer
Developer
Posts: 1391
Joined: Mon Oct 22, 2007 16:47

Re: Crash on startup in Congestion 64 MAP20

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

User avatar
NeuralStunner
O'Neill with it.
Posts: 252
Joined: Tue Dec 29, 2009 3:46
Location: IN SPACE
Contact:

Re: Crash on startup in Congestion 64 MAP20

Post by NeuralStunner » Thu Oct 13, 2011 22:42

[stupid]Could you disable "telefragging" during the first gametic?[/stupid]
Dean Koontz wrote:Human beings can always be relied upon to exert, with vigor, their God-given right to be stupid.
Spoiler: System Specs

User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7143
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Re: Crash on startup in Congestion 64 MAP20

Post by Graf Zahl » Fri Oct 14, 2011 0:03

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

User avatar
Gez
Developer
Developer
Posts: 1391
Joined: Mon Oct 22, 2007 16:47

Re: Crash on startup in Congestion 64 MAP20

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

User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7143
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Re: Crash on startup in Congestion 64 MAP20

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

User avatar
NeuralStunner
O'Neill with it.
Posts: 252
Joined: Tue Dec 29, 2009 3:46
Location: IN SPACE
Contact:

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

Post by NeuralStunner » 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.)
Attachments
CrashReport_LightsPK3.zip
(21.83 KiB) Downloaded 117 times
Dean Koontz wrote:Human beings can always be relied upon to exert, with vigor, their God-given right to be stupid.
Spoiler: System Specs

User avatar
Enjay
There is no dark side in the moon, really...
Developer
Developer
Posts: 4557
Joined: Tue Aug 30, 2005 23:19
Location: Scotland
Contact:

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

Post by Enjay » 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]

User avatar
NeuralStunner
O'Neill with it.
Posts: 252
Joined: Tue Dec 29, 2009 3:46
Location: IN SPACE
Contact:

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

Post by NeuralStunner » 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...
Dean Koontz wrote:Human beings can always be relied upon to exert, with vigor, their God-given right to be stupid.
Spoiler: System Specs

User avatar
Enjay
There is no dark side in the moon, really...
Developer
Developer
Posts: 4557
Joined: Tue Aug 30, 2005 23:19
Location: Scotland
Contact:

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

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

User avatar
Gez
Developer
Developer
Posts: 1391
Joined: Mon Oct 22, 2007 16:47

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

Post by Gez » Mon Dec 26, 2011 12:23

Might be related to this.

User avatar
NeuralStunner
O'Neill with it.
Posts: 252
Joined: Tue Dec 29, 2009 3:46
Location: IN SPACE
Contact:

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

Post by NeuralStunner » 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."
Dean Koontz wrote:Human beings can always be relied upon to exert, with vigor, their God-given right to be stupid.
Spoiler: System Specs

User avatar
Enjay
There is no dark side in the moon, really...
Developer
Developer
Posts: 4557
Joined: Tue Aug 30, 2005 23:19
Location: Scotland
Contact:

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

Post by Enjay » 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
}

Locked

Return to “Closed Bugs”

Who is online

Users browsing this forum: No registered users and 0 guests