I’m working on a group project, and I have been trying to troubleshoot this issue for days.
5 people have packaged the project. For 2 people, the packages come out fine. For 3 people, an assert fails and crashes the project when going from the main menu to the opening level.
Assertion failed: bIsOptional && Property->ElementSize >= 256 [File:D:\build++UE5\Sync\Engine\Source\Runtime\CoreUObject\Private\Serialization\UnversionedPropertySerialization.cpp] [Line: 126]
I have tried looking up the assert to determine what to look for, but I cannot find any information about it online. When tracing it, I see it’s called by UStruct and UClass. Beyond that, I can’t narrow it down to anything meaningful.
We’re using Plastic for source control, and we have confirmed everyone’s Visual Studio settings and project config files are the same. At first I thought it might be a CPU issue since the 2 working packages were made by people with AMD CPUs and 2 of the busted packages were made by people with Intel CPUs. However, the 3rd busted package was made by someone with an AMD CPU.
Does anyone have any ideas on what the issue MIGHT be or how to narrow it down?
It might be due to data corruption.
Are you able to catch the crash in the debugger in a build with debugging symbols available? If it is a development configuration even better.
If you are able to catching on the debugger, some things to take a look at can be
- Can you see what struct type name is being serialized? It should be part of the UScruct or UClass object that is being serialized. That might give you a hint of what asset is involved.
- Is the archive in an error state? That assert should come from a callstack containing
SerializeUnversionedProperties. There, there is a UnderlyingArchive local variable, That is the variable you should try to inspect. If the archive it is in an error state, it would confirm that something went wrong before.
1 Like
After attaching the debugger to one of the crashing packages, I got the following call stack:
So, an actor component seems to be part of the issue.
If I allow the debugger to work through the crash 1 breakpoint at a time, I eventually get this error:
Fatal error: [File:D:\build\++UE5\Sync\Engine\Source\Runtime\CoreUObject\Private\Serialization\AsyncLoading.cpp] [Line: 3558]
ProSaveComponent /Game/.../Maps/Croft/L_Croft.L_Croft:PersistentLevel.BP_Buildable_Ceiling_Triangle_C_1.ProSave: Serial size mismatch: Got 2094, Expected 19
I should note the actor presented has changed between 2 different actors in the 3 runs I did, but the actor component has stayed the same.
I am not able to inspect the UnderlyingArchive variable because the debugger will only show me the Assembly. Is that due to using a Development build instead of a DebugGame build?
I still don’t understand why this error would be happening when packaged with certain machines and not others.
Call stack 1 breakpoint at a time:
Yes, if you can only see assembly it is because it is optimized away. A Debug build might allow you to inspect that variable.
Another alternative is, if you are building the engine from source, surround the method with the macros
UE_DISABLE_OPTIMIZATION
UE_ENABLE_OPTIMIZATION
That will disable optimization just for the surrounded method (remember revert this change after you are done debugging)
That said, it is unclear to me why it would fail only when packaged from specific machines.
If not done already, I would try to sync the project from scratch in new location in the affected machine, and then do a new build/package. This is to discard any potential content issue in the project due to a bad sync.
Lastly, if I read the log snippet right, is the component that always fail named ProSaveComponent? If so, does that component have custom serialization code? If the answer is yes, there might be an issue with the implementation of that component.
1 Like
Yes, you did read the log snippet correctly. The name of the component is ProSaveComponent. It saves specific data from the parent actor to a json file and reads that data when the level is loaded, and the component has guards against non-existent data or json files.
I am currently waiting for one of the people who makes crashing packages to submit a DebugGame package for me to debug with.
