GC FSM - Event-driven, hierarchical finite state machines in blueprint

[gamecentric (Alberto Barbati)]

@eanticev

I’m concerned that the FWeakObjectPtr::GetEvenIfUnreachable() will not work. I tried that myself and it just introduces a crash a few minutes later due to another cascading issue.

I may have oversimplified in my post, replacing Get() with GetEvenIfUnreachable() is a start but it’s not enough to fix the issue. Did you reproduce those crashes with the v1.5.3 version?

@eanticev

Also, consider what we’re doing here by making this change… we now might be not garbage collecting the FSM at the right time, thus leaving it running even if an object is unreachable.

When the context object is destroyed, the FSMs will stop ticking and will therefore stop “running” immediately. It’s true, however, that there may be a situation where the root state object and all its FSMs stay around until the next garbage collection cycle, instead of being purged as soon as its context object is. The situation occurs only if the context object becomes unreachable without first being marked pending kill. YMMV, but I believe this case doesn’t occur very often and even if it does, the situation eventually heals itself without memory leaks.

@eanticev

I’m not sure what your test-case looks like, but you ideally have to run the scripts I suggested because the engine behaves slightly differently in editor than standalone.
I’m happy to connect and go over these issues via screenshare and figure out a solution.

That’s a good advice. The standalone indeed has a different behaviour from the editor, so I must be more careful and check that also. That said, I could not reproduce bugs nor crashes with your test project using v1.5.3 even on standalone.

@eanticev

If I remember correctly with this line change I was getting a crash after a few minutes on line 87 in GCFSMUtilities where it’s trying to get

auto context = rootState->GetContextObject();

Instead of this check

return context && !context->IsPendingKill();

You might need to do something like:

return context->IsValidLowLevel() && !context->IsPendingKill();

I seem to remember that just a nullptr check is not always 100% as opposed to IsValidLowLevel

The problem here could be that there is a situation where the call to AddReferencedObject() might nullify rootState. It has nothing to do with context having an invalid value. Adding a null check on rootState might probably be safe, I just would like to understand if it’s really needed, because I did not encounter this problem during regular use. BTW, due to the way the value of context variable is obtained (it’s the value of a UPROPERTY), a null check is ok, using IsValidLowLevel() would be a huge waste of time.

Anyway, I’m thinking of rewriting this part of GC FSM. It looks a bit fragile and I would like to make it less dependent from garbage collection internal details.