Page 1 of 1
[r918] Crash playing hexen
Posted: Sun Aug 29, 2010 7:11
by 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.
Re: [r918] Crash playing hexen
Posted: Sun Aug 29, 2010 11:36
by 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.
Re: [r918] Crash playing hexen
Posted: Sun Aug 29, 2010 16:21
by 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.
Re: [r918] Crash playing hexen
Posted: Mon Aug 30, 2010 13:58
by Gez
Good for you, but the crash on MAP34 still happens to me.
I also got it with r880 (official 1.5.0 build).
Re: [r918] Crash playing hexen
Posted: Tue Aug 31, 2010 3:45
by 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.
Re: [r918] Crash playing hexen
Posted: Tue Aug 31, 2010 9:21
by Enjay
Do you still have the savegame file? If so, posting it here may help.
Re: [r918] Crash playing hexen
Posted: Tue Aug 31, 2010 15:15
by 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.
Re: [r918] Crash playing hexen
Posted: Tue Aug 31, 2010 16:28
by 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.
Re: [r918] Crash playing hexen
Posted: Tue Aug 31, 2010 18:56
by 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.
Re: [r918] Crash playing hexen
Posted: Tue Aug 31, 2010 19:56
by 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.
Re: [r918] Crash playing hexen
Posted: Tue Aug 31, 2010 20:20
by Gez
Cached nodes are not the issue:
http://pastebin.com/QfcTtCwK
Re: [r918] Crash playing hexen
Posted: Tue Aug 31, 2010 20:54
by 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.
Re: [r918] Crash playing hexen
Posted: Tue Aug 31, 2010 21:13
by Gez
Re: [r918] Crash playing hexen
Posted: Tue Aug 31, 2010 21:48
by 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.
Re: [r918] Crash playing hexen
Posted: Tue Aug 31, 2010 22:15
by 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.