DRD Team

http://www.doomworld.com/idgames/?id=16123

Load the wad, goto E1M1, when you see the monster coming to you then teleported. After some seconds later, game crashed and I get a crash report window.

I put a savegame but maybe not needed, because it's on beginning of level. You load map, about 3-6 seconds later, BLAM! It crashed.

Using latest GZDooM on DRD Team SVN Page, r886 and r888(this one still display r886 - ZDooM r2532) both crashed.
Tested on ZDooM r2532, it's fine.
Try killed my ini, make a new one, still crash.

Then I downloaded r878, it's not crash anymore.

Works up to r883.

In r884, it crashes for me right when loading the map, when attempting to delete[] sidetemp. I don't even get to look at the monster and wait a few seconds.

How about ZDoom? I have to admit that this is code I don't really want to look at.

No crash in ZDoom (it just looks ugly because there are massive HOMs all over the level).

No crash in GZDoom if I comment out the added call to P_LoopSidedefs(). :/

Try in ZDoom with gennodes 1.

I think Randy needs to have a look. Without that second P_LoopSidedefs call the polyobject code will make a mess after an internal nodebuild and I don't have an idea how else to handle it.

I've looked a bit into it and it seems actually pretty simple.

First, P_AllocateSideDefs() creates sidetemp[] with a size that depends on numvertexes and numsides. In that map they're 11479 and 19769. Then P_LoopSidedefs() is called a first time. NV and NS are still 11479 and 19769. And then P_LoopSidedefs is called a second time, but this time the values have risen to 20965 and 19769. Since the array already exists, it's not reallocated, and you get access violation galore.

I do not get crashes anymore.

Ok, I backported the fix to ZDoom.