Search Unity

Bug Burst Crash in Windows standalone

Discussion in 'Burst' started by Mogthew, Nov 30, 2020.

  1. Mogthew

    Mogthew

    Joined:
    Jan 30, 2013
    Posts:
    18
    I'm getting a crash in windows standalone that appears to be coming from burst.

    0x00007FFC4E515B8F (lib_burst_generated) Ordinal0
    0x00007FFC4E5A0DC2 (lib_burst_generated) afb3b5e5ccb43fc552440fa9471b2318
    0x00007FFC1D167F8B (UnityPlayer) UnityMain
    0x00007FFC1D1685FC (UnityPlayer) UnityMain
    0x00007FFC1D165FB6 (UnityPlayer) UnityMain
    0x00007FFC1D1664E7 (UnityPlayer) UnityMain
    0x00007FFC1D167A00 (UnityPlayer) UnityMain
    0x00007FFC1D25A388 (UnityPlayer) UnityMain
    0x00007FFC7E2E7034 (KERNEL32) BaseThreadInitThunk
    0x00007FFC7E47CEC1 (ntdll) RtlUserThreadStart

    Versions
    unity     2020.2.b12
    burst 1.4.1
    collections 0.14.0-preview.16
    entities 0.16.0-preview.21
     
    Mogthew, Nov 30, 2020
    #1

  2. tertle

    tertle

    Joined:
    Jan 25, 2011
    Posts:
    3,761
    This just an exception from your burst code. Any exception at runtime will cause a crash in burst.

    You need to debug it with the dmp file to see where its coming from.
     
    Last edited: Nov 30, 2020
    tertle, Nov 30, 2020
    #2
    Lee_Hammerton likes this.

  3. Mogthew

    Mogthew

    Joined:
    Jan 30, 2013
    Posts:
    18
    Can someone else confirm this? I'm pretty sure what you are saying is incorrect, but I could be mistaken.

    EDIT: I just noticed your edit, and it makes more sense now.
     
    Last edited: Nov 30, 2020
    Mogthew, Nov 30, 2020
    #3

  4. Lee_Hammerton

    Lee_Hammerton

    Unity Technologies

    Joined:
    Jul 26, 2018
    Posts:
    118
    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).
     
    Lee_Hammerton, Nov 30, 2020
    #4

  5. Mogthew

    Mogthew

    Joined:
    Jan 30, 2013
    Posts:
    18
    I've re-built the binary and captured a crash:"

    It's happening here

    Code (CSharp):
    1.         public byte* GetComponentDataWithTypeRO(Entity entity, int typeIndex, ref LookupCache cache)
    2.         {
    3.             /* this is line 744 */return ChunkDataUtility.GetComponentDataWithTypeRO(m_EntityInChunkByEntity[entity.Index].Chunk, m_ArchetypeByEntity[entity.Index], m_EntityInChunkByEntity[entity.Index].IndexInChunk, typeIndex, ref cache);
    4.         }
    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 :)
     
    Last edited: Nov 30, 2020
    Mogthew, Nov 30, 2020
    #5
    Lee_Hammerton likes this.

  6. tertle

    tertle

    Joined:
    Jan 25, 2011
    Posts:
    3,761
    So you can see your exact issue from your stack

    In your ShipVisibilitySystem ProcessShipSystemChangedEvents

    You're either passing in a ComponentDataFromEntity<ShipVisibilityData>
    Or doing a
    GetComponent<ShipVisibilityData>(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<ShipVisibilityData> 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.
     
    tertle, Nov 30, 2020
    #6

  7. Mogthew

    Mogthew

    Joined:
    Jan 30, 2013
    Posts:
    18
    That seems to be the only sensible conclusion, either the entity is malformed or doesn't exist.

    Oh well, at least I have a good idea about where to look to solve this.

    Big thanks to both of you (@tertle and @Lee_Hammerton ) !
     
    Mogthew, Nov 30, 2020
    #7
    Lee_Hammerton likes this.

  8. Chaosed0

    Chaosed0

    Joined:
    Jun 19, 2013
    Posts:
    23
    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:

    Code (csharp):
    1. ========== OUTPUTTING STACK TRACE ==================
    2.  
    3. 0x00007FFC2C7A56C9 (UnityPlayer) UnityMain
    4. 0x00007FFC2C7A4CCA (UnityPlayer) UnityMain
    5. 0x00007FFC2B85A03C (UnityPlayer) UnityMain
    6. 0x00007FFC273DA5B5 (lib_burst_generated) Ordinal0
    7. 0x00007FFC273D978B (lib_burst_generated) Ordinal0
    8. 0x00007FFC273D94F1 (lib_burst_generated) Ordinal0
    9. 0x00007FFC2B85842B (UnityPlayer) UnityMain
    10. 0x00007FFC2B858C56 (UnityPlayer) UnityMain
    11. 0x00007FFC2B840E0D (UnityPlayer) UnityMain
    12. 0x00007FFC2B843152 (UnityPlayer) UnityMain
    13. 0x00007FFC2B84874C (UnityPlayer) UnityMain
    14. 0x00007FFC2BC14F3D (UnityPlayer) UnityMain
    15. 0x00007FFC8EF954E0 (KERNEL32) BaseThreadInitThunk
    16. 0x00007FFC8F1E485B (ntdll) RtlUserThreadStart
    17.  
    18. ========== END OF 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?
     
    Chaosed0, Mar 4, 2022
    #8
    Aspect26 likes this.

  9. Chaosed0

    Chaosed0

    Joined:
    Jun 19, 2013
    Posts:
    23
    We've solved this issue by force-generating the symbols for lib_burst_generated in builds through the following checkbox in Project Settings.

    upload_2022-4-27_14-47-50.png

    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.
     
    Chaosed0, Apr 27, 2022
    #9

  10. tim_jones

    tim_jones

    Unity Technologies

    Joined:
    May 2, 2019
    Posts:
    287
    > 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.

    Apologies for the delay in replying about this. This was a bug, and we'll include the bugfix in an upcoming Burst release.
     
    tim_jones, Jun 28, 2022
    #10
    Chaosed0 likes this.

  11. VirtusH

    VirtusH

    Joined:
    Aug 18, 2015
    Posts:
    95
    Sorry for necro, but was this ever fixed?

    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?
     
    VirtusH, Jun 21, 2023
    #11

  12. tertle

    tertle

    Joined:
    Jan 25, 2011
    Posts:
    3,761
    We're using 1.8.7 in 2021, just manually add to your manifest.

    You should be able to see exactly what line of code caused your crash from the .dmp file
     
    tertle, Jun 22, 2023
    #12
    VirtusH likes this.

  13. VirtusH

    VirtusH

    Joined:
    Aug 18, 2015
    Posts:
    95
    Really? How do I get the .dmp file to show that?
    And thanks, I'll update!

    Looking up how to debug burst crashes unfortunately leads to no documentation and few forum threads. :\
     
    VirtusH, Jun 23, 2023
    #13