This question was created in reference to: [Crash in EnumerateUniformBufferResource due to GCed [Content removed]
Hello, I was trying to follow up on the question I referred to, but it was permanently closed unanswered.
[Attachment Removed]
Here is another thread where the problem similar to ours, but happens with OpenGl, but we use DX12. The language of that ticket is Chinese so I didn’t take a risk to write there in English.
[Content removed]
[Attachment Removed]
Hello, I apologize about the previous ticket. Let me take a look and dig in here. Thanks for reminding and bringing the ticket to our attention.
[Attachment Removed]
Hello!
We happen to be seeing the same issue in shipping builds from our users and occasionally from our internal test bot (on a Testing build) we’ve yet to identify the exact thing, most likely MiD, causing the issue although we are looking at a few places in our BPs where there may have been some MiD shared / re-used, similar to what Anton has been reporting in their previous thread.
By the way if you have any pointer in how you identified the offending MiD in your case Anton it would be greatly appreciated!
In any case, we would be interested to hear more about what could lead render thread command to still be in-flight after the MiD has been GC’ed and what would be the options to either fix that systemically, or add better tracking to be able to sanitize our data usage if it’s indeed the root issue.
Note that we’re also on UE5.2 / Dx12 if that’s any indication of something specific with that version w.r.t. material instance dynamics.
Thanks!
[Attachment Removed]
Anton,
Was the issue was resolve by using the existing Kismet function to create the MID?
[Attachment Removed]
Hi Jason, did you have a chance to take a look on the issue?
[Attachment Removed]
Apologies, just trying to follow up on this thread. Is there any news on that?
[Attachment Removed]
Hey Anthony, IIRC it was identified in a following way. We looked in the command lists before/after crashed one. It gave us an information about which static mesh was used with that deleted uniform buffer. Then we searched over a codebase for usage of that SM and figured out the system creates/re-uses MiD.
Currently we are assuming that it is not safe to re-use MiD if they have Outer with life time bound to SM or anything tied to level/world.
[Attachment Removed]
Heya Anton - How is “the system” creating the MiDs?
[Attachment Removed]
Hey Joshua, now it creates it like this:
UMaterialInstanceDynamic* NewDynamicMaterial = UMaterialInstanceDynamic::Create(ParentMaterial, GetTransientPackage());
[Attachment Removed]
Heya Anton - I see that UKismetMaterialLibrary::CreateDynamicMaterialInstance also sets the RF_Transient Flag on the created MiD.
[Image Removed]
If you’re still experiencing issues - I wonder if doing the same might solve them?
[Attachment Removed]
We have no such issues anymore since that. I’m pretty sure that if you use Kismet helper for that, it also should work as it sets transient package inside (only for game worlds). At same time it could be that the issue you experience has different root cause (may be you create MID with transient package but store MIDs in containers without UPROPERTY, or may be you store them in USTRUCT which is in turn stored in UOBJECT but without UPROPERTY, etc. etc.). It also depends in engine version. Ours is 5.2. In your version GC rules could be different
[Attachment Removed]