After upgrade from 5.6.1 to 5.7.2, we noticed that our compile all blueprints test sometimes crashes, around 1 in 5 runs or so, it seems to happen only when compiling our UI widgets. Just in case that matters we do use ModelViewViewModel plugin to build our widgets. At first we thought it was some circular dependencies, but after fixing all that we could find it just reduced the chance of the crash, but it still happens.
Looking at the “Value” that fails to serialize looks corrupted, while “PropertyPath” looks valid.
- PropertyPath "bCompareAltSlot" TFieldPath<FField>
- Value 0x0000021939cbef60 Name="Category" FField * &
+ __vfptr 0x0000000000001f1e {???, ???, ???, ???, ???, ???, ???, ???, ???, ???, ???, ???} void * *
+ ClassPrivate 0x00007fff00001f1e (Name=???) FFieldClass *
+ Owner 0x0000021ae4820ff0 Name=Illegal name (length > NAME_SIZE)_109 FFieldVariant
+ Next 0x0000000e0000000e Name=??? FField *
+ NamePrivate "Category" FName
FlagsPrivate RF_NoFlags (0) EObjectFlags
+ MetaDataMap 0x00000000000092d5 Empty TMap<FName,FString,FDefaultSetAllocator,TDefaultMapHashableKeyFuncs<FName,FString,0>> *
Any ideas on what could cause this, or tips on how to approach this issue?
[Attachment Removed]
Steps to Reproduce
Run CompileAllBlueprints commandlet that targets all content.
[Attachment Removed]
We are encountering the same issue. It appears that blueprints referenced in View Bindings are not being tracked by the compiler (in UBlueprint::CachedDependencies and CachedDependents), so when the dependency blueprint is recompiled the dependent BP is left with stale pointers to its properties in the UFunction generated for the binding, which will cause a crash in a subsequent Serialize call for replacing other object references.
[Attachment Removed]
Hi there,
Sorry for the delay, I’ll look at getting a repro case together to see if we can track this down. I’ll post back soon once we have a fix and/or a bug ticket for tracking.
Best,
Cody
[Attachment Removed]
Hi [mention removed], do you have an example of a view binding that reproduces this? We’re explicitly adding the Viewmodel itself to the dependency list for the widget blueprint, so that should link in any of it’s own dependencies that you might be able to bind to via a view binding. I’m hacking in a bit of code to explicitly define the compile order in RecompileAllBlueprints, but I haven’t had any luck finding a configuration that triggers the crash yet.
[Attachment Removed]
Hi Cody, the problem is that (as far as I’m seeing) only direct dependencies get included in CachedDependencies and recompiled, so depending on the viewmodel which then depends on the recompiling blueprint isn’t enough to avoid the crash.
The binding that triggered it was of the form:
CommonNumericTextBlock.SetCurrentValue(SafeDivide(ViewModel->Member->FloatValue, 100))In case it matters, the indirect dependency was itself a subclass of ViewModel but wasn’t included in the widget’s viewmodels. Our fix for the crash was to add it as a viewmodel and use a direct binding.
I will see if I can reproduce it in a sample project.
[Attachment Removed]
Hi all,
Sharing an update here; we fixed the simpler case of directly bound viewmodels changing layout in CL#37799166 (5.6), so I tried rolling back that fix locally to see if I could get it to solidly reproduce before continuing on to the “VM-within-a-VM” case that we seem to be hitting here. I saw it reproduce exactly one time and never again, so your explanation definitely sounds plausible but it’s been a challenge to get a case we can use to verify any sort of fix. Perhaps a step in the right direction would be to add the VM’s dependencies as additional Widget Blueprint dependencies in UMVVMWidgetBlueprintExtension_View::HandleBeginCompilation:
if (UBlueprint* ViewModelBP = Cast<UBlueprint>(ViewModelClass->ClassGeneratedBy))
{
ViewModelBP->CachedDependents.Add(WidgetBlueprint);
WidgetBlueprint->CachedDependencies.Add(ViewModelBP);
WidgetBlueprint->CachedDependencies.Append(ViewModelBP->CachedDependencies);
for (TWeakObjectPtr<UBlueprint> Dependency : ViewModelBP->CachedDependencies)
{
Dependency->CachedDependents.Add(WidgetBlueprint);
}
}
[mention removed] If you have this consistently reproducing in your own project, it might be worth trying to update that code and seeing if you still run into crashes. I’ll post back if I’m able to make any headway on a consistent repro.
Best,
Cody
[Attachment Removed]
Tried the proposed fix, without it, the test failed 1/5 just like before, with the fix I’ve run 50 in the row and they all have passed without issues so it seems like this solves the issue.
[Attachment Removed]
Glad to hear that worked! I’ll check with the team to see if this is an appropriate fix or if there are other concerns here.
[Attachment Removed]