Re: Zforms example gzdoom crash

Sun Sep 05, 2021 4:38 pm

Jarewill wrote:Oh, I see. Thanks for the information!
However I already started using a master of ZForms, (not current one, but a recent one, unsure which) so should I switch back to 1.0 or wait for the 2.0 version that's in the works?

You should use the master. 1.0 is vastly different, and is affected by another severe issue. This issue hasn't been fixed in GZDoom yet, and likely won't be anytime soon, due to the nature of the problem.

Re: Zforms example gzdoom crash

Mon Sep 06, 2021 5:50 am

phantombeta, In the bug thread (posting here so as not to clutter up the bugs one with scripting discussions), you wrote.

phantombeta wrote:
  • Start the game and do "stat gc" in the console.
  • ...
  • Memory allocations will now be too fast for the GC to keep up with. Once "Alloc" reaches "Thresh", it'll be stuck in the Sweep phase.
If you add "menuactive = OnNoPause;" to the Init function of PDAMenu (In "zscript/PDAMenu.zc"), the issue never pops up. Once Alloc reaches Thresh, it starts collecting dead objects just fine.

I just wanted to check a couple of things.

Firstly, I added menuactive = OnNoPause; to the init section of one of my own PDA projects. It seems to do exactly what you said it would. I added it as the last line in the init function. Is that the best place for it, or does it not really matter?

I know that the core issue obviously still exists, so I assume that this is a workaround rather than a fix (?) but I also assume that it does now make my PDA mod safe from any issues that this bug might cause. Is that correct?

Re: Zforms example gzdoom crash

Wed Sep 08, 2021 3:45 am

Putting that in init is fine, the issue is that it's... not really a fix, because this has significant behavioral changes to the UI (notably, it doesn't pause the game any more so the player can be killed during it as monsters will still be roaming around). The exact technical details here is that essentially the garbage collector only runs proportional to the amount of ticking thinkers in the level, because that's assumed to represent a high upper bound on how much garbage can be made per tick. But in pausing menus thinkers aren't ticking so nothing gets garbage collected. ZForms 2.0 fixes this almost completely by simply stopping elements from creating garbage every render (by switching a bunch of things to structs instead of classes) - it can still be triggered in ZForms 2.0 though if you create and destroy a lot of elements (because elements absolutely have to be classes). It's just an unfortunate thing to be aware of with the current menu system, and will probably take a GC rewrite to fix on GZDoom's side.

Also, the related crash here was caused by a performance improvement I made to Shape2D rendering in GZDoom, the first implementation was a bit sloppy and (after a change was made to destroy Shape2D data in their Destroy method) was causing the shape's data to be deleted before the renderer got to it. Now the renderer takes shared ownership of the shape data so that it can hold onto it even beyond the shape's destruction time. ZForms 2.0 doesn't trigger the crash in stable GZDoom simply because it's smarter about Shape2D rendering and keeps a cache around, not destroying them every frame.

Re: Zforms example gzdoom crash

Wed Sep 08, 2021 6:25 am

Thanks for the explanation. I had been testing in an area where there were no monsters so the monsters still being active wasn't apparent. You're right, of course, testing with some summoned monsters, they kept wandering and attacking while I stood there with the PDA open.