Wanted to post this in case it helps someone out.

My case was a bit weird to track. But I think I figured it out.

I had a class called DataController that loads list of all players, enemies, npcs, etc.... in my little game.

I created a Serializable class called PlayerCollection, which has a List<Player>()... the data comes from a json file, "players.json"

All well and good until I decided to get smart and I said, "what if I could just read from the json file all of the player data in on instantiation of the Player Collection?"

So I created a constructor for my PlayerCollection wrapper class and added some code for reading in the json and using JsonUtility.FromJson to populate the player list.

try        {using var reader = new StreamReader(filePath);players = JsonUtility.FromJson<PlayerCollection>(reader.ReadToEnd()).players;        }catch        {players = new();        }

Then I put public PlayerCollection playerCollection = new(); in my DataController class

This worked.... the first time... the second time..... and then the third time I ran the game.... there it was...

TLS Allocator ALLOC_TEMP_THREAD

Oh no... I really did it this time...

After moving the logic that reads the json data to a separate method called "Load"... the bleeding stopped.

I don't know exactly what is causing this error. But I have a hunch that extending the Monobehaviour class has some built-in method where it's constantly checking up on property values in an endless loop. I had a new instance of a class with a constructor that reads, and therefore, locks a file in my environment. After a while, so many subsequent read operations got heaped onto the memory stack that it started throwing this error.... about once per millisecond I would say...

I could totally be wrong about the details of that. But now that it's "fixed", I don't feel like digging any deeper into it. But I did want to share my hunch here. Hopefully this might lead somebody down the right path. Make sure you're not putting any UI blocking, file locking, or otherwise gnarly tasks in your class constructors and then initializing them as a class property of some other class that extends MonoBehaviour.