This callstack shows a crash within burst compiled code, In your build folder, within the Data/Plugins folder there should be a lib_burst_generated.txt which will allow you to pinpoint the job in question (see this video
at 27:18 approx) which will explain this. Or alternatively as @tertle points out you can load the .dmp file and work it out that way (make sure the lib_burst_generated.pdb is in the symbol search path).
public byte* GetComponentDataWithTypeRO(Entity entity, int typeIndex, ref LookupCache cache)
{
/* this is line 744 */return ChunkDataUtility.GetComponentDataWithTypeRO(m_EntityInChunkByEntity[entity.Index].Chunk, m_ArchetypeByEntity[entity.Index], m_EntityInChunkByEntity[entity.Index].IndexInChunk, typeIndex, ref cache);
}
Which is in the EntityComponentStore.cs file
This is what the stack looks like
[Inline Frame] lib_burst_generated.dll!Unity.Entities.EntityComponentStore.GetComponentDataWithTypeRO(Unity.Entities.EntityComponentStore.445 *) Line 744 C Symbols loaded.
[Inline Frame]
I’m going to look into the code and see if I can spot it doing anything weird. Good video! Love your work
In your ShipVisibilitySystem ProcessShipSystemChangedEvents
You’re either passing in a ComponentDataFromEntity
Or doing a
GetComponent(entity)
and the entity doesn’t have the component ShipVisibilityData
You need to validate your logic if you expect it to always have the component or do a HasComponent check beforehand
If you using an Entity reference, the entity you are targeting might be destroyed and not exist anymore.
-edit-
not sure why you deleted your full stack, it showed the exact issue.
Is the method of tracking down the job through the hash in the stacktrace still applicable in Burst 1.6? I have a crash dump with the following stacktrace:
Note the “Ordinal0” where the hash would normally be.
With the changes in Burst 1.6 to omit the function entrypoint from exception strings, and with this missing information, I’m not sure how else to track down the crash. Is there somewhere else I should be looking?
We’ve solved this issue by force-generating the symbols for lib_burst_generated in builds through the following checkbox in Project Settings.
By doing this, the Player.log gets symbolicated and you can retrieve crash information that way. You can also remove that pdb before uploading your production build, and run a post-mortem on the dump files using the pdb file.
Not sure if lib_burst_generated.txt is at all useful anymore, given that the hashes don’t ever seem to be included in the stacktrace.
On the latest (available) version of burst (1.8.3, 1.8.7 not available in 2021 LTS) we routinely struggle to debug burst-related crashes. Often either the lib_burst_generated.txt doesn’t contain the hash shown in the crash, or the crashlog/stacktrace doesn’t have a hash.
Is there any documentation on finding the causes of burst-related crashes?
