Random Crash

[Daryn]

I wanted to post this in hopes that someone can help figure out what went wrong. The report says there was an access violation, but I'll be damned if I can make much sense of it.

https://www.dropbox.com/scl/fi/ztumuebr ... qbnpf&dl=0

Hope it's possible to figure out what happened.

[Rachael]

Screenshot from the minidump:


Issue here is thing->Sector was null (crash was in line 1099 of p_maputl.cpp) - but don't know what happened to make it that, there isn't much info you can get from a minidump.

[Daryn]

Well, it's something at least. It's happened on two different maps, though I don't know if the other one that happened earlier crashed in the same way.

In making maps, is there anything one might do by mistake that could lead to something like this? I have a few scripts that move 3D Floors, but I doubt that might cause it.

Maybe I should use the debug version of GZDoom, maybe that would give more info?

[Rachael]

Only if you are able to get all the info needed from the debugger. The most important thing to know is what actor caused it, and the last thing that actor did, where it is in the level (or specifically, whether it is out of bounds in the level), and where it was in the last tic.

If that sounds too complicated - then it's going to require someone else loading up the mod in question with the mapset and trying to reproduce the issue themselves.

And - all that effort would be for nothing if it can be "quickfixed" (i.e. return on an actor->Sector==nullptr) - not sure if that is possible in this case or not, and I can't test that without the setup in question.

[Daryn]

Well, I'll ask my friend to go over the maps and see if there is any way that an actor could end up in null space for starters. Beyond that, I'm a bit over my head, as I don't know whether it's my own code or PB's that may be causing this. Both times the crash happened, my friend was just walking through an area, and it was a different map each time. It also isn't helping that it seems to take a good bit of time for the issue to actually happen.

The best I could do is provide the files, if you'd be willing to look into it.

[Daryn]

I will prepare a package for whomever wants to have a look at this. For now, though, and for completeness, here's the earlier dump.

https://www.dropbox.com/scl/fi/wketaz4a ... lg000&dl=0

[Daryn]

I just wanted to follow up on this. I spent the last couple of days working on this and I think we figured it out. It has nothing to do with bad code in an actor, or bad map data, or anything like that. No, that would make sense.

The problem, as it seems to be, is UDB.

One thing we often do is just load up a map in UDB, start playing, and then keep on playing through. In the past, this has never been an issue. I know it's not the intended use for this function of UDB, but it hadn't been a problem before.

Well, with the recent updates to UDB, something's changed. Given the whole program is being rejiggered to build on a newer version of Visual Studio, I'm not all that surprised, but the way it manifests is just bizarre.

Firstly, when you press F9, you get a security prompt from windows, with a box you must uncheck to not get that prompt again. That's fine, easy to do, but the dialog box often ends up underneath UDB so it is a bit of a pain to get to that first time.

Then, on occasion, when starting a map, I'm not able to move or aim at all, until I press my right mouse button and then a get a slight screen flash and I have control. The same thing happens after exiting the game with UDB in the background.

I'd ignored these little issues, but once we started seeing crashes, we thought what if there is a weird interaction going on between UDB and GZDoom?

To test our theory, I made a batch file that loads GZDoom, PB, KAI, and our working folder, much like I do in the release package for Dragon Sector.

We were both able to play through the maps flawlessly. When we try to do it with UDB running, as mentioned above, that's when the crash happens.

My theory is that UDB somehow doesn't realize GZDoom is still running and deltes its temp wads out from under it.

[Rachael]

You might be onto something with the security thing - but if the problem is indeed files being removed I don't think that would manifest as a crash in GZDoom until a map change.

[Daryn]

I'm as mystified as you. It doesn't make a lot of sense, but since taking UDB out of the equation, we've not experienced a single crash. If it deleted files that were no longer being accessed by GZDoom, it shouldn't effect anything, but I don't know the ins and outs of GZDoom as well as you.