We’ve been having these crashes with a callstack that is always in the async loading queue, and it seems to be happening because we’re attempting to edit some asset that is in the async loading queue. It’s a very difficult crash to repro because it would require a project with a substantial amount of assets and strikes randomly based on the nature of the editor still loading many assets in the background. Is there a known workaround for this? Like removing an asset we’re trying to edit off the async loading queue?
Hi Ali,
I’d like to know more about how you end up with an asset in edition that is still being loaded. Normally, most UObject that are being loaded should be invisible to the game thread since we apply filtering on them. If you query Object->HasAnyInternalFlags(EInternalObjectFlags_AsyncLoading) and it returns true before you edit it… I would try to trace back where you found this object from and go from there. There are many ways you could end up with an object still loading… one of the most notorious ways for this to happen is when registering to delegates in UObject constructors, where the UObject can then get called too soon since it is still being loaded.
We’ve moved most of those delegate registrations to safer places like PostLoad, but I’m sure there are some remaining. There is probably a handful of other means to leak UObject still being loaded, so any info you could track down would be valuable.
Of course you could just flush all async loading before edition as a temporary fix, but it would be preferable to find the root cause instead for best editor efficiency.
Thanks
Danny