Search Unity

Bug Can't build project in any version over 2021.2.8f1

Discussion in 'Editor & General Support' started by Kajta, Jun 23, 2022.

  1. Kajta

    Kajta

    Joined:
    Feb 13, 2016
    Posts:
    11
    We have upgraded our project from 2021.2.8f1 to Unity 2021.3.4f1 because of an issue in the in 2021.2.8f1 that prevents us from using Shadowmask/Distance Shadowmask modes because it won't build custom shaders with the correct shader keywords in that version, so we just jumped to the next in line version that worked: 2021.3.4f1.

    Now, whenever a build is created using any version of Unity after: 2021.2.8f1, the build crashes either at startup, or at a Resources.LoadAll call, with the message that eiter globalgamemanagers.asset or the resources.assets file is corrupted, I have pinpointed the crash towards the specific files that are creating the issue, but these files are not changed in any way, but including these files in the build (pre-loaded assets causes the globalgamemanager.assets to get corrupt, while having the files in the Resources folder causes the resources.assets to get corrupt, makes sense).

    These files are ScriptableObjects that hold a list of custom classes that are serialized using the [SerializeReference] attribute.I followed all the rules regarding [SerializeReference] and this setup has worked for well over a year in other Unity versions (going back to 2021.2.8f1 results in working builds).

    I pinpointed it further down towards 1 of the classes that is serialized using [SerializeReference], it seems to crash whenever that class instance holds a reference to another custom MonoBehaviour script in the project (No matter if the reference is set, or is serialized as null) whatever .asset files they are builded in becomes corrupted.

    I cannot for the life of me figure out what is happening, and why serialization is breaking in builds, in editor every works completely fine, no errors or warnings.

    During some testing and building, I have managed to change the error from a corrupted .assets file to: Size overflow in allocator. being called right at the Resources.Load call, but I failed to find any information regarding that error.

    If someone from the Unity team could help us out, it's been over 2 weeks now since we haven't been able to produce a single working build, and we are kind of stuck on the matter for now.
     
  2. tessellation

    tessellation

    Joined:
    Aug 11, 2015
    Posts:
    390
    @Kajta Curious if you solved this problem? We're having a similar hard-crash in Unity Editor after using Resources.LoadAll in the editor. Any time we access one of those ScriptableObjects from the array that's returned, the Editor crashes. Unity 2021.3.25f1
     
  3. Kurt-Dekker

    Kurt-Dekker

    Joined:
    Mar 16, 2013
    Posts:
    38,735
    Resources.LoadAll<T>() can be problematic if you don't provide a subdirectory to look in.

    As much as I like Resources.Load/LoadAll, it does behave in some VERY brain-dead ways.

    If you do a Resources.LoadAll<T>("/"), what Unity does under the hood is:

    - load EVERY resource it can find under that path (eg, deserialize into RAM)
    ------> when I tested this a few years back, it loaded ALL of them at once, spiking RAM usage
    - iterate them all and decide if it is of type T and if so, add it to the array
    - return the array when done

    So you can see this might cause problems without proper directory "namespacing."

    Usually textures (and possibly audio) are the main culprits. Put other stuff you care about into subdirectories always and things will work a lot better.
     
  4. tessellation

    tessellation

    Joined:
    Aug 11, 2015
    Posts:
    390
    Thanks for the reply and advise. In our case it turned out to be a C# stack overflow bug. Unity Editor just crashes without any warning or log indicating such. So if you stack overflow in a class property code and that property is being displayed in the debugger, it may not be obvious what part of the code is causing Unity Editor to crash. In our case it looked like LoadAll but it was a property being exposed in the debugger!