AsyncTask node memory usage

I have made a blueprint node that executes loading of images in the background in the vein of this.
However, for some reason, results are never garbage collected, causing huge increments in memory usage.
I’m using TFuture and broadcast the value after it is valid, yet releasing its content manually still causes the very linear memory increase.

I do not know whether the node or the TFuture or the UTexture2D are causing the leak, with no idea on how to find out. Though I suspect the TFuture is guilty of this as I have a reverse function node (writing images to disk) with the same problem, though less of an issue as it is only used in editor.

Any advice?

279445-node.png

To add to that, reloading the level does not free up the memory, so the reference to it for the garbage collector is lost somewhere.

So the async is not to blame as the “Import File as Texture2D” node from Epic has the same problem.
I have noticed that loading the textures result in ever-increasing “Texture Memory Used” mounting to ridiculous size and never garbage collected, even when stopping PIE!

That might deserve a bug report in the submission form.

But I think it’s more likely me handling some data wrongly than a bug in Unreal. If a staff member could chime in, that would be helpful.

Nevermind I got it.

No just kidding; so I made a node that cleans up the transient texture:

void UBPLibrary::CleanupTransientTexture(UTexture2D* Texture)
{
	for (int32 i = 0; Texture->GetNumMips() - 1; ++i) Texture->StreamOut(i);
	Texture->PlatformData->Mips[0].BulkData.RemoveBulkData();
	Texture->ConditionalBeginDestroy();
}

after that I force garbage collection (though the data has already been cleaned up) for the widgets containing those textures. I think the issue was that the texture being referenced in a widget (even after it is removed from its parent) kept it in memory for a very long time, never being cleaned up automatically and thus flooding VRAM and then RAM.
I cleaned up the reference before but never the bulk data, which is why it did not seem to work.