How to enable DEBUG_STACK_LEAK in StackAllocator.h - to debug issue in 2019.2.

Am working on project in 2019.2.2 and yesterday after using the profiler to locate and resize large textures to a smaller size I am getting memory allocation issues and the game plays very sluggish in the edito ( although confusing builds and plays just like it did prior to the issue). (I reimported the asset store asset that I was resizing textures on but that did not resolve issue)

In my console logs I see a warning to do this, which seems like it help me debug the issues but have not been able to locate how to actually do this. Can someone advise how to turn this on?

Internal: Stack allocator ALLOC_TEMP_THREAD has unfreed allocations, size 135296

To Debug, enable the define: DEBUG_STACK_LEAK in StackAllocator.h. This will output the callstacks of the leaked allocations

And in the informational part of Console I now see hundreds of records like this (with different object references and byte sizes)

Allocation of 108 bytes at 0000022B37503B60

In the meantime, going to backup project and try moving to the latest version of 2019.2.5 (due to issues with the replacement of LWRP with URP in the past reluncant to move past 2019.2)

1 Like

I’m having the same issue, but I didn’t do anything with textures.
I was working on some very simple C# scripts, like spawn an enemy here, decrease some thing’s health there, and suddenly I started getting these messages. Pretty annoying. I’ll try rolling back a bit and test if that helped, but it sure is gonna cost me a day’s work…

[update]
so, before rolling back I decided to fidle around some more. After trying to find the assets that were causing the problem with no success I closed the project to roll it back. Then, in the last second I decided to export some of the assets I had changed and try to import them into the older version and, lo and behold, upon reopening the editor the issue had disapeared.
I commited my work now, though I feel really queezy about it…
It’s really akward to have an issue appear and the disappear, not knowing whether it might come out the woodwork again.

I am not sure exactly what i did to resolve this but it seems like it was something to do with layers (was something in the rendering part). I reimported the layers from base template (am using invector (the best)) and then manually readded my layers. Dont know if that helps.

How do I do this?
How do I get this file?

Bump 1

Have you tried:

  • Running ‘Assets/Reimport All’ (CTRL+R | CMD+R)
  • Closing the editor => Deleting the directories ‘Library’, ‘Temp’, ‘Obj’ (if they exist) => Re-launching the editor

?

I hear these two generic swiss-army hotfixes work for many folks, but if your issue persists, we’re gonna need to know:

  • Your current Unity Editor version (talking specifically to the bumper, @fredholmsimon )
  • Whether or not your project is under source control (git, plastic, svn, …)
  • Your game’s build target(s) (at least the current active one)
  • Scripting Backend and API Compatibility Level (from Player Settings)

Hope the first two tips fix it for you, though.
:spades: LP

Bumb 2

The question is “How to get the file StackAllocator”.
I’ve had memory leaks across versions and I’ve got a big project so there’s no way I can find out which area is affected without this file, it happens randomly (sometimes in-game, sometimes while just in editor)

Bump 3

The StackAllocator.h file is in Unity’s C++ engine code, so there is no way for you to access this or to begin to debug this leak. Those of us who get this problem have to just wait until Unity fixes it.

All we can do is submit an issue that reproduces the problem, upvote issues on Unity’s issue tracker that pertain to it, and hope they address it.

If it’s related to https://issuetracker.unity3d.com/issues/tls-allocator-alloc-temp-tls-errors-when-rendering-shaders , it looks like the problem has been fixed in 2021.2.9, which has not been released yet.

2 Likes

Note, in Unity 2022.1.0a13 we added a command line switch “-diag-temp-memory-leak-validation” which allows you to enable this diagnostic (the error message was changed accordingly to point to this command line switch).

That is awesome news!
I’m in 2020.3 for now, is there a way to back-port?
But anyhow, cool

Is there any chance this will be back-ported to 2020.3?
I’m on 2020.3.31f1 right now and have really bad issues with this.
And I’m not in a position to update to 2022.

Good news is that we are actively discussing this right now. Sadly because of nature of this change its backport will take some time to do.

OK, cool. I’d be EXTREMELY happy if you decide to backport.

Me too. This has been in our project since at least the upgrade to 2020 LTS, always happens during first import, but impossible to debug.

Any news on this?