[HELP] Problem with gzd3.7 stabilty on BoA [SOLVED]

[Ozymandias81]

Hello everybody,

As the title says I am experiencing some several stability issues with dev builds of GZDoom-pre3.7### while I run Blade of Agony during my dev tests for the project: whenever I try to run map C3M1, 99,9% times I get a crash or a dropoff (I mean no reports, just closes) after something probably related to garbage collection (I AM ASSUMING) makes GZDoom to crash or quit.

I am saying this because I also had a run with GZDoom 3.6.0 stable release with most recent build of BoA (GZDBuilder playtest, IPK3 file or pk3 file running under Doom2.wad) and I didn't had any issues playing the map or messing with stuff.

For this reason, exist an ISSUE opened on our Github repository for BoA where I try to keep track (and explain) on what's going on, it also seems that I am not the only one on the team to have these problems (Tormentor667 said to me a couple of months ago, he will let me know when he can though).

You can have a rough idea jumping directly to the VIDEO I have post on Issue comments and follow what I have wrote on the text file inside the 7z, and also the issue contains most recent CrashReport if devs wants to take a look at it

It also seems that if I use the FREEZE command or KILL MONSTERS in game, crash doesn't happen anymore so I am quite confident that it should be related to garbage collection and enemies behavior somehow or probably JIT merge on the engine (but which is an exotic materia for my knowledge, sorry)

Due to the fact that this problem is giving me craps a lot and it is nearly impossible to provide examples, I decided to write here a post in the hope to get this at least addressed by some GZDoom devs or anyone else very experienced with Zscript in general (if this really depends by it).

NOTE: Exist a certain way to reproduce the issue: just start a new game, select Chapter 3, finish C3INTRO map and go to the Briefing Room while in HQs to start C3 Mission 1, go outside and meet sgt. Ascher and start the new mission - Crash may happen during C3M1 intro or after 20 mins of gameplay

My actual PC config has been slightly updated since past times, maybe this would be of help due to the fact that my GPU can't be updated anymore:

- AMD-FX Vishera Am3+ 6300 6core (before November I had a DualCore)
- Palit GeForce GT610 1024mb drivers v391.35 (latest)
- 4gb ram ddr3 1333mhz
- Windows 7 64bit Service Pack 1 with .NET Framework 4.7

Thank you very much for any kind of help or hints you'll give to me

[_mental_]

The last crash happened in FPortalSceneState::EndFrame() function. Pointer to destructor in HWPortal vtable seems to be bogus, or vptr itself is wrong.
In other words, it has nothing to do with the garbage collection as portals are not subject of it. JIT merge is not related to this particular crash either.

Do you have other crash reports from the same build? At least, they will help to rule out hardware issues and potential of (V)RAM case.
4 GB RAM + 1 GB VRAM config seems to be too low for huge mods like BoA.

Also, are you sure that 3.6.0 with the same settings using the same version of mod works fine?
Please note that you need to compare versions under the exact conditions.

[Ozymandias81]

With a fresh "install" of most recent gzdoom devbuild I get those crashes/dropoffs seen in that video.

Then I simply drag & drop IPK3 or pk3 file of BoA, the same one used above, inside a new fresh "install" of gzdoom 3.6.0 and play and no issues happens.
Later I'll prepare another video where I do these things, c3m1 has very complicated portals and probably it is related to actors which crosses them ( since crashes on 3.7 doesn't happen if I freeze or kill monsters)

[Ozymandias81]

Okay I have played smoothly for more than 25 mins on c3m1, playing Chapter 3 from the start and no crashes happened with wolf_boa.pk3 and Doom2.wad under gzdoom-x64-g3.7pre-879-gfb7156331 ... Later I will let you know if nothing bad happens even with IPK3 or while doing tests from GZDBuilder (always bugfix)
Probably this could have solved the problem on my end, but for what I can see on commits the pull doesn't have successfull checks

I will also try with previous build r777 too and post here CrashReports if possible under several circumstances (IPK3, pk3 and gzdbuilder playtest)

[_mental_]

If g3.7pre-879-gfb7156331 solved the problem for you, no need to test with older builds. It's better to test with the latest in order to ensure that the issue was fixed.

[Ozymandias81]

Thank you very much! I did a second run with r879, this time with IPK3 and no issues happened. Now gonna try via GZDBuilder then I'll let you know in some mins... What was exactly the cause of the problem then on prevous builds, just to know? This problem really gave me craps for the whole development of 3.7, but now seems all good

[EDIT]: Not a single problem even while playtesting from GZDBuilder (git folder as pk3, always did like this). THANK YOU VERY MUCH! Will update this thread if further issues will happen

[Graf Zahl]

The last crash happened in FPortalSceneState::EndFrame() function. Pointer to destructor in HWPortal vtable seems to be bogus, or vptr itself is wrong.
In other words, it has nothing to do with the garbage collection as portals are not subject of it. JIT merge is not related to this particular crash either.

That one sounds like the same concurrency issue with portals in the renderer which I fixed yesterday or the day before, so it should be gone. It was the same kinds of weird crashes I got with ZZYZX's test map.
This one definitely could have caused all sorts of stability issues in portal-heavy maps.

[Ozymandias81]

That one sounds like the same concurrency issue with portals in the renderer which I fixed yesterday or the day before, ...

Do you mean the commit mentioned on my previous reply? Noticed that as well, these issues are pretty eerie to spot for someone like me which doesn't have enough knowledge to compile gzdoom builds (something that I plan to change in 2019, installing VS 2017 and gathering informations about compiling GZDoom dev build by myself) - And I wonder if these infos are still feasible just to clarify

[Graf Zahl]

Yes, precisely that. Such concurrency problems give the weirdest kinds of crashes where even a good programmer often doesn't know at first what is up.

For compiling GZDoom, these days it should be sufficient to get the repo, run CMake, set the proper compile target, generate a project and compile it. It doesn't need any external dependencies, although for the 64 bit build I replace the included JPEG library with libjpeg-turbo, but that's not a requirement and would necessitate a bit more setup.

[Rachael]

Don't you at least still need the Windows SDK and Visual Studio?

[Graf Zahl]

Of course you need those, but the SDK shipping with VS is fully sufficient, unless you need XP compatibility.