Version 4.14.1+ Random Freeze

[Daryn]

We are having a random and very frustrating issue with the newest versions of GZDoom when playing Dragon Sector.

What happens is that after a while, the game freezes up completely. The music keeps on playing, but everything else is locked up. I don't get an error or crash to desktop, it's just frozen and I have to Task Manager out.

The isssue does not occur at all with the 4.14.0a release on Windows. I don't know if the newer versions on Linux have this problem, but the Windows version is what we're on.

We're using Windows 11 24H2
Nvidia Driver 566.36 because anything newer destroys the performance completely.

The biggest frustration is that though we can get the freeze to happen every time we play it with the newer versions, when it happens is always different, which is making it hard to figure out what's going on.

If you want to try it, grab the full pack over on this post.
https://www.moddb.com/mods/dragon-secto ... -available

And simply replace the bundled version of GZDoom with 4.14.1. I am unable to provide specific triggers, as it feels random.

Lewisk3 also mentioned freezes with the newer version on his own mod, so I know it isn't just me.

I wish I could give you something more solid to work with.

[Hellser]

The random part is the big thing here. This mod is... quite a lot to test. So far - maybe halfway through the first map - on the near latest git build that I have, I haven't experienced any freezing. The only time I can think of when GZDoom freezes like this is if a moving actor is goes into a 0-tic loop - but since it works on an older version of GZDoom, I have no clue.

[Daryn]

Yeah, this is the frustrating bit. We thought it was working great with the new version, but then it froze up in the third map. So it is one of those things that can take a long time to actually happen, and when it does happen on this end, I don't have any way of digging into what was actually happening.

[Daryn]

Just to add, we loaded from an autosave, and it froze up not long after. On 4.14.2 release. I'll get the save file to you asap, but I am not sure if you'll be able to load it. Still, I'll provide it.

[Rachael]

Keep in mind that the actor state checker will always run while any actor's "tics" value is 0. So that means if there are a chain of 0-tic states, especially if they are looped, it will just run forever. Older versions of GZDoom were not just magically immune to this. It's possible there's a bug in the mod itself that is hidden until you run it on a more recent version of GZDoom.

Other than that, I couldn't tell you what could possibly be going wrong here. I could possibly add a cvar to the state checker that forces it to track how many state transitions it has done for the current actor on the current tick and error out to the console after it's reached an abysmally high value. But doing that would likely require it being exclusive to debug builds of GZDoom; the state checker is a performance concern because it runs for every actor on every tick while the game is running, meaning it runs hundreds if not thousands of times per second even on the original Doom1/2 mapsets.

[Daryn]

While I and many other mods use 0 tic states, I can't think of any instance where I would loop that. I do know of some problems in PB a while back where 0 tic death states causes issues.

We're also not talking a jump of major versions here. From .0 to .1, and I honestly couldn't say if anything changed in the state checker in that update. You would have a better idea there.

But if it is mod specific, it is going to be a nightmare to track down. A cvar like that, would be helpful. Or maybe some kind of key combination to force a break and dump to file.

I'm just spitballing here, because thus far, it is happening pretty consistantly in this map, but it is happening with different monsters and weapons in play. So trying to eyeball it and figure out a pattern is proving impossible.

Either way, Rachael, I want to thank you for the help, and for helping bring GZDoom to us. We really appreciate it. We could have never made this mod on any other port, period. Whatever the cause is, we'll get to the bottom of it.

[Rachael]

If you can get it to a point where I can reliably trigger it, even with a save file, I can force a break inside of a debug build and figure out where it's causing problems.

Alternatively, you can try and trigger it in this build: https://drive.google.com/file/d/10UUU6y ... sp=sharing
Compile source: https://github.com/madame-rachelle/gzdo ... 567c4acca0

Either way, Rachael, I want to thank you for the help, and for helping bring GZDoom to us. We really appreciate it. We could have never made this mod on any other port, period. Whatever the cause is, we'll get to the bottom of it.

Thank you, I always strive to make GZDoom better.

[Daryn]

I've downloaded the test build and I'm going to give it some testing. I'll report back if/when I find something.

[Rachael]

If it still freezes on that build and doesn't give you the message about infinite states, then there's an infinite loop in the code somewhere instead - either in the ZScript or inside GZDoom itself.

[Boondorl]

Are you using the version of Project Brutality bundled with your mod or the latest build? If using the latest, it wouldn't hurt to test it with the bundled one to rule out a possible bug that got introduced by the mod itself

[Daryn]

Hey, sorry for the delay in getting back.

So I deliberately created an actor with a 0 state loop to test out the behavior, and I see that you've got it setup to remove the actor after printing the console message. Once we've got some more time, we'll do a full test through the maps with this build and see what happens.

We are using the latest build of PB, which as far as I could tell, hasn't changed that much, but I should rule that out, too. I know that the version that's bundled with our mod will freeze up, though, as that's what we were using when we tested 4.14.1.

I'll report back when I have more info.

Thanks y'all!

[Daryn]

The plot seems to be thickening. I don't think it's a 0 tick loop. With the test build we didn't get any of those warnings. We did however experience freezing and crashing to desktop. I don't know if it is with Zscript or GZDoom at this point, but something is definitely up. Again, none of this happens on 4.14.0a. I am wondering if this could have anything to do with the thread handling that came in on 4.14.1.

The other person we've got testing this also mentioned that none of his mods would load with 4.14.2. I'm not sure why that would be, so I have to chalk that one up as an error on his end somewhere.

At this point, though, I'm still as mystified.

[Rachael]

So then indeed there is likely a problem within the GZDoom code itself. But now we need to know what sets it off in order to fix it. Consider both monsters and ambient objects in this case. Especially consider obscure functions that you don't commonly see used in mods - since they're tested less they tend to be more buggy than other functions.

[Daryn]

I'm going to read over my code with a critical eye. I will see if anything sticks out at me. There's a few things specifically I do that I might need to re-evaluate. I may post some stuff if I'm not sure it couldn't cause a problem.

[Boondorl]

Realistically I think the easiest way to track this down is gonna just be hooking the debugger up to a Debug build and playing until it freezes. This is probably too difficult to find by eyeballing without shear luck playing a part