Inexplicable crash on certain maps.

[Sodaholic]

On certain maps, the engine inexplicably crashes upon map startup. It says something about an "Access violation", or something, trying to read address 00000000.

The map file is here: http://files.drdteam.org/index.php/file ... lipped.zip
I will only give the password to the zip to developers, as this map is meant to be private. (will be public in a few months, but it's not ready for release yet)

Here is the crash report: http://files.drdteam.org/index.php/file ... report.zip

[Blzut3]

Your nodes are broken for some reason. Deleting the ZNODES lump allows it to run fine.

[Gez]

ZDBSP issue?

[Blzut3]

Since I don't really know what to expect out of the nodes I can't do anything myself but it's crashing on line 942 of p_setup.cpp:

Code: Select all

0x000000000065cd41 in P_LoadGLZSegs (data=..., type=1) at /home/blzut3/Code/ZDoom/trunk/src/p_setup.cpp:942
942                                     seg->frontsector = ldef->sidedef[side]->sector;
(gdb) bt
#0  0x000000000065cd41 in P_LoadGLZSegs (data=..., type=1) at /home/blzut3/Code/ZDoom/trunk/src/p_setup.cpp:942
#1  0x000000000065d2ca in LoadZNodes (data=..., glnodes=1) at /home/blzut3/Code/ZDoom/trunk/src/p_setup.cpp:1052
#2  0x000000000065d6de in P_LoadZNodes (dalump=..., id=1313621848)
    at /home/blzut3/Code/ZDoom/trunk/src/p_setup.cpp:1146
#3  0x0000000000663f5c in P_SetupLevel (lumpname=0xc23e38 "map02", position=0)
    at /home/blzut3/Code/ZDoom/trunk/src/p_setup.cpp:3682
#4  0x00000000005b2339 in G_DoLoadLevel (position=0, autosave=false)
    at /home/blzut3/Code/ZDoom/trunk/src/g_level.cpp:877
#5  0x00000000005b1691 in G_InitNew (mapname=0xe3614c "map02", bTitleLevel=false)
    at /home/blzut3/Code/ZDoom/trunk/src/g_level.cpp:449
#6  0x0000000000589bc7 in D_DoomMain () at /home/blzut3/Code/ZDoom/trunk/src/d_main.cpp:2323
#7  0x000000000054b50b in main (argc=7, argv=0x7fffffffe0e8) at /home/blzut3/Code/ZDoom/trunk/src/sdl/i_main.cpp:325

Locals

Code: Select all

ldef = 0x1a72de8
seg = 0x14cf000
line = 3291
lineword = 3291
v1 = 2637
partner = 5
side = 1 '\001'
j = 0
i = 16

ldef contains:

Code: Select all

$2 = {v1 = 0x148abd0, v2 = 0x148ac68, dx = 5242880, dy = 0, flags = 1, activation = 1, special = 0, Alpha = 65536, 
  id = -1, args = {0, 0, 0, 0, 0}, firstid = 0, nextid = 0, sidedef = {0x1b66850, 0x0}, bbox = {58720256, 58720256, 
    47185920, 52428800}, slopetype = ST_HORIZONTAL, frontsector = 0x19ee980, backsector = 0x0, validcount = 0}

As you can see since side = 1, it's trying to use a NULL pointer.

[Sodaholic]

While this probably still needs to be fixed, that version of the map has been scrapped anyway.

ZDBSP issue?

It most certainly is. I've been having this problem ever since I switched over to UDMF

[randi]

Fixed.

ZDBSP issue?

It most certainly is. I've been having this problem ever since I switched over to UDMF

Considering that just running the map through ZDBSP produces working nodes, I doubt it. Examining the nodes indicates that they were built for a map with 3876 vertexes. This map has 3864. This suggests that these nodes don't belong with this map and came from somewhere else.

[Gez]

Code: Select all

if (orgVerts > (DWORD)numvertexes)

Is there a reason it's not simply an inequality here? Does it work if orgVerts < (DWORD)numvertexes? Or is that scenario already rejected elsewhere (and then why wasn't an inequality used there)?

[randi]

Because traditional nodes add extra vertices to the VERTEXES lumps. If you'd like to verify that ZDBSP does remove these excess vertices when it builds -z nodes, I'd be happy to make it an inequality. Mostly, I just didn't feel like checking what ZDBSP did with them, so I wrote the check to work with the case that is definitely wrong.