Why are simulated ability tasks not getting removed from client's UActorChannel's ReplicationMap?

My logs are littered with PostReceivedBunch: Object == NULL messages. After a couple days of debugging, I’ve narrowed it down to only occurring on GameplayTasks (any ability task derived from AbilityTask_ApplyRootMotion_Base) that are simulated (bSimulatedTask = true).

It appears that that these tasks are never removed from the ReplicationMap of the simulating client’s UActorChannel. As expected, every time these tasks are called, it adds a new replicator to the channel’s ReplicationMap via FindOrCreateReplicator(). So what ends up happening is PostReceivedBunch() gets called on all the non removed replicators which have a null ObjectPtr property, thus trigger the PostReceivedBunch: Object == NULL message.

I have verified EndTask() gets called on both the server and simulating client, as well as ensured that the replicator gets unmapped on the client channel via MoveMappedObjectToUnmapped() in ReadContentBlockHeader().

I never got this problem prior to upgrading from 4.17.2 to 4.20.2. Does anyone know if this a known bug? Or better yet, have any insight how I might further troubleshoot/fix this?

Any assistance would be appreciated, for I’ve spent far too long troubleshooting this.

Thanks!

Thanks for the response DarkwindRichard!

Whoops, I overlooked the fact that this was a verbose log. So are you suggesting that this message does not indicate a problem? In either case, it still seems problematic since the ReplicationMap will grow indefinitely for each usage of a simulated task since they never get removed. Is this not a memory leak?

Hi Get Gooder,

If the object is successfully unmapped like you say, then it shouldn’t be anything to worry about. If you look at the source, you can see that the mapped object list is eventually flushed (which empties the array) and the unmapped list eventually has its elements removed and cleaned up.

Hey DarkwindRichard,

Not sure what the guidelines are around reopening a resolved question, so I apologize if this is bad form. However, I’ve confirmed that bSimulatedTask’s are never removed from the client’s ReplicationMap. I created a test map that essentially just has a character activating a bSimulatedTask every few seconds. I let it run for 10-15 minutes and noticed that the ReplicationMap had over a thousand different entries for each activation of that task, all containing a NULL ObjectPtr property.

I’ve verified this behavior on the following tasks:

  • AbilityTask_ApplyRootMotionConstantForce
  • AbilityTask_ApplyRootMotionJumpForce
  • AbilityTask_ApplyRootMotionMoveToActorForce
  • AbilityTask_MoveToLocation

Memory usage also slowly increased throughout the duration of the test.

Hi Get Gooder,

Would it be possible for you to create a small project that can reproduce the issue? If not, could you provide some repro steps? If so, I can get a bug filed for the issue.

Sure, I’ll see if I can reproduce this on a fresh project in the next couple days.

DarkwindRichard,

I’ve reproduced this on a fresh project. How do you want me to send it to you?

I’ve created a github repo containing the project and repro steps. Let me know if there is anything else you need from me!

Hi Get Gooder,

Thank you for your reproduction project. I was able to confirm that the replication map does grow indefinitely with the simulated ability tasks, though it is kind of slow (about 400 entries for three actors in 8 minutes), in both 4.20.3 and 4.21.0. Unfortunately I do not have a workaround that you could use in the meantime, but I have gone ahead and reported the bug so the gameplay team will at least be made aware of it.

Hi Get Gooder,

PostReceivedBunch: Object == NULL is a verbose log. Is your only problem that that is being spammed in your log?

Hi Get Gooder,

Sure thing! I’ve gone ahead and proposed that the issue be made public. Once that’s been done, you can follow its progress on the issues site.

No problem! Is there anyway for me to track the status of the bug? Or better yet, will you comment here if a workaround becomes available?