Klaudiusz,
Ok, so we’ve identified the problem, at least in the newest version of the engine. It’s the same issue, but there’s potential (although unlikely) that there are additional things happening on your end.
The Replication code always assumed that Classes (and Structs and Functions) would never be destroyed at runtime. The assumption was made because these types of things are really more like Meta Data descriptions of classes than actual gameplay objects. This is the assumption that’s causing the problem.
For every class, we create an FRepLayout that knows how the replicated properties are laid out in memory, and how to serialize / deserialize the replicated properties for networking.
The problem is that FRepLayout is storing hard references to the properties. I didn’t catch this at first, because it’s not happening through the normal property system. Instead, it’s happening through AddReferences.
Basically, the fix is to move these references from the Class level to the Object level and when the Class is destroyed just remove the FRepLayout.
We haven’t implemented a fix for this yet, but after discussion it doesn’t sound that bad. Basically, in FRepLayout change the Owner member to be a TWeakObjectPtr (so we know when the class gets destroyed) and move the AddReferences method onto FRepState (which is per object). Finally, To prevent memory leaks from repeatedly created FRepLayouts, occasionally clean out the UNetDriver::RepLayoutMap so that any RepLayouts whose Owner is null (e.g., owner has been destroyed) gets removed.
I’ll try to have a CL for this by next week, but hopefully you can work on a solution in the interim with the info I’ve provided.
Thanks,
Jon