[Jobs][Lags] JobTempAlloc has allocations that are more than 4 frames old

Sorry was meant to reply before but got caught up.

So yeah the majority of the time this warning shows up it has nothing to do with container allocations and the message itself really gives you no feedback which is why it's such a confusing warning. From experience though, it's nearly always an issue with jobs and jobhandles, usually one being lost due to a different path in code being taken.

It sounds like your issue might relate to some internal jobs related to the frame debugger, might want to file a bug report in that case.

 

Yes. And after more tests, it is clear that it is the problem of using SRP batchers with Frame Debugger. Turning off the SRP batchers makes everything fine.

 

I experienced "JobTempAlloc..." warning with Addressable Asset System when I use textures with enabled option "Use Crunch Compression", both under Unity 2018 and 2019. Disable crunch compression fixed a problem for me.

 

I also saw these errors in the console after the project was transferred to 2019.2. Previously, in 2018.4 these errors were not.
I also get errors if the game is running, the statistics window is on, and I move objects in the scene.
Disabling the statistics window and restarting Unity helped me.

 

I'm seeing a report in the wild with massive "Internal: JobTempAlloc has allocations that are more than 4 frames old - this is not allowed and likely a leak" etc spam in the output log. It's a final build using Unity 2018.4.2f1. Anything I can do with this? Super hesitant to upgrade a shipping project to Unity 2019+, but if it's necessary, it can be done.

Edit: this player's entire machine freezes, forcing a full restart.
Edit 2: not using ECS or job system or any similar fancy stuff, and not seeing a single reference to job stuff when doing Find All in my solution.

 

@laeusnb When you say, out in the wild, do you mean in production run. If a temp job is created in a fixed update frame and then 4 regular update frames are run before the next fixed update frame (where the frame can be disposed) this will pop up. I found limiting my frame rate via VSync fixed this issue.

 

Thanks -- I mean, a pre-release Steam build of the game. I also should have mentioned (and added an Edit) that I'm not using the job system or ECS at all.

 

Do you use the async navmesh package? I think that's where mine stem from. It's always just been an annoyance though, I've never had any crashes or user problems.

 

Yeah I get this message when using async back navmesh at runtime, not sure how to get rid of it

 

I would also strongly advice against upgrading when close to release. Try pinpointing the problem. Can you reproduce the problem on your machine? The 4 frames warning may occur only on slower machines due to jobs taking more frames to complete, so maybe you can mimic your player's specs and setup.

Also, Unity uses ECS under the hood for some stuff, and as others have mentioned, async navmesh baking is known to produce these warnings. But for me at least, it has not caused a complete freeze. It might be possible that the freeze and warnings are unrelated.

 

It happens on high fps too.
High or low config.
4 frames, it's just not enough.

 

I cannot reproduce it on my machine at all (and have had no reports of freezing/crashing from other playtesters). This player has a pretty beefy machine. I'll keep digging to see what it is. I do not use async navmesh. Thanks for the input.

 

If the player has a beefy machine, means his framerate is too high and some job Unity has created (probably in the fixed update part) is not being disposed within four Update frames. I wish they would fix this and not spam the console with this message. Or allow us to up the warning to 10 - 20 frames.

 

I had this warning: "Internal: deleting an allocation that is older than its permitted lifetime of 4 frames (age = 12)" until I closed Tab Profiler. May be it's help somebody.

 

This is known issue in 2018.4.16 and 17.

See:
https://unity3d.com/unity/beta/2018.4.17f1
https://issuetracker.unity3d.com/issues/asset-bundles-fail-to-load-when-using-async-loading-methods

 

I'ts been a known issue since 2018 =o

 

I have also been getting the "JobTempAlloc has allocations that are more than 4 frames old" warning. In my case, I have used the GetRawTextureData method on a Texture2D, and passed the pointer to the NativeArray it returns to my IJob struct. The job clears the texture, but I have plans for much more complicated drawings, many of which will take longer than four frames to complete. In my code here, I simply repeat the loop that clears the 512x512 texture ten times. It ends up taking about 240ms, and always generates the "more than 4 frames" warning.

This is pretty surprising because the documentation for GetRawTextureData says this:

So there is no allocation happening at all. Also, setting NativeLeakDetectionMode to Disabled has no effect.

My code is below. I'm on the lastest LTS Unity, 2018..4.18f1. Should I report this as a bug?

Code (CSharp):

1. using System.Collections;
2. using UnityEngine;
3. using Unity.Jobs;
4. using Unity.Collections;
5.  
6. public class ChangeTexture : MonoBehaviour
7. {
8.     Job job;
9.     JobHandle jobHandle;
10.  
11.     Texture2D tex;
12.  
13.     void Start()
14.     {
15.         tex = (Texture2D)GetComponent<Renderer>().material.mainTexture;
16.     }
17.  
18.     private void OnMouseDown()
19.     {
20.         NativeArray<byte> pixels = tex.GetRawTextureData<byte>();
21.  
22.         MyJob job = new MyJob
23.         {
24.             pixels = pixels,
25.         };
26.  
27.         jobHandle = job.Schedule();
28.  
29.         StartCoroutine(WaitForJob());
30.     }
31.  
32.     IEnumerator WaitForJob()
33.     {
34.         while (jobHandle.IsCompleted == false)
35.         {
36.             yield return null;
37.         }
38.  
39.         jobHandle.Complete();
40.  
41.         tex.Apply();
42.     }
43. }
44.  
45. struct MyJob : IJob
46. {
47.     public NativeArray<byte> pixels;
48.  
49.     public void Execute()
50.     {
51.         for (int r = 0; r < 10; ++r)
52.         {
53.             for (int i = 0; i < pixels.Length; i = i + 4)
54.             {
55.                 pixels[i] = 0xFF;
56.                 pixels[i + 1] = 0xFF;
57.                 pixels[i + 2] = 0xFF;
58.                 pixels[i + 3] = 0xFF;
59.             }
60.         }
61.     }
62. }
63.  

 

Here's a rewrite of my code that replaces Unity's IJob system with .NET's Thread class. Not certain it guarantees memory coherence in the Texture2D's raw data.

Code (CSharp):

1. using System.Collections;
2. using System.Threading;
3. using Unity.Collections;
4. using UnityEngine;
5.  
6. public class ChangeTextureThread : MonoBehaviour
7. {
8.     Texture2D tex;
9.  
10.     void Start()
11.     {
12.         tex = (Texture2D)GetComponent<Renderer>().material.mainTexture;
13.     }
14.  
15.     private void OnMouseDown()
16.     {
17.         NativeArray<byte> pixels = tex.GetRawTextureData<byte>();
18.  
19.         PixJob job = new PixJob
20.         {
21.             pixels = pixels,
22.         };
23.  
24.         Thread jobThread = new Thread(job.Execute);
25.         jobThread.Start();
26.  
27.         StartCoroutine(WaitForJob(jobThread));
28.     }
29.  
30.     IEnumerator WaitForJob(Thread jobThread)
31.     {
32.         while (jobThread.IsAlive)
33.         {
34.             yield return null;
35.         }
36.  
37.         tex.Apply();
38.     }
39. }
40.  
41. class PixJob
42. {
43.     public NativeArray<byte> pixels;
44.  
45.     public void Execute()
46.     {
47.         for (int r = 0; r < 10; ++r)
48.         {
49.             for (int i = 0; i < pixels.Length; i = i + 4)
50.             {
51.                 pixels[i] = 0xFF;
52.                 pixels[i + 1] = 0xFF;
53.                 pixels[i + 2] = 0xFF;
54.                 pixels[i + 3] = 0xFF;
55.             }
56.         }
57.     }
58. }

 

Hey, I'm getting this issue and I'm not using the jobs system at all, and I'm not aware of any plugin I'm using that does. How can I diagnose and get rid of this warning?

 

@Marco-Trivellato
@Joachim_Ante
@timjohansson
All the pings because it's been years and this is still clogging up our output logs to no end! Running 2018.4.16 LTS, still full of this. Is this supposed to have been addressed? Why is there still no way to just turn it off?

 

Any updates? I've gotten this error too, it freezes the players machine. Getting this loading to a main menu where jobs and ECS aren't being used at all, but also loading normal scenes. I might limit the frame rate in loading screens.

 

Update: Clamping Application.targetFrameRate to 250 seems to have fixed this issue for me.
Alternatively turning vsync on does as well.

 

Still happens in unity 2019.3.9

Not using jobs at all.
The issue for me seems to be something with SceneManager.LoadSceneAsync and something inside the scene but who knows what.

Loading the scene normally throws no errors.

 

@lejean Unity under the hood is using Jobs more and more. My guess is some load thing that has been called is running more than 4 frames and then Unity is dumping those errors.

I would really like to have those errors disabled for buildings. Spamming the logs is bad for a release. Most of the time these allocations are disposed of, just outside of 4 frames.

 

You can do something like this in Awake or in RuntimeInitializeOnLoadMethod to disable all logs completely:

Code (CSharp):

1. #if !DEVELOPMENT_BUILD && !UNITY_EDITOR
2.         Debug.unityLogger.logEnabled = false;
3. #endif

Not ideal solution, but for the release builds that should be enough. AFAIK exceptions are still outputted to the log file.

On the flip side, I agree.
This warning is really pointless for the common folks like us, because we don't have an access to the native C++ side of the engine.

 

If I remember correctly I actually tried to do just that to stop my dedicated servers from constantly spamming (spoiler: they still do) but even that didn't work. I overwrote the entire logger class and tried to intercept all log handlers, but it wasn't attached to any of them. These are not being passed through the internal logger and go straight to the log files making it even more annoying.

 

Maybe we can have a solution/fix from any Unity Team member.
Not VSync or any other "hack" solution
@LeonhardP
@superpig
@timjohansson
@Joachim_Ante

 

Related issue: https://issuetracker.unity3d.com/is...ning-jobs-causes-internal-jobtempalloc-errors

My solution to not use JobHandle.CombineDependencies in any long-running job. It is not good for perfomance, but at least no more warnings and crashes.

 

When targeting 120fps or more, 4 frames is not enough.
"Long" running jobs is very "relative".

 

That view count.

And if a solution is found, it would be nice for it to be not exclusive to 2020 beta alpha whatever, but backported to previous versions as well (the versions that existed in 2018, when the users started to report the issue...2 years ago)

Thank you, I really hope to see that fixed one day

Regarding the 'better not use this or that to avoid this mess', I'll just note that this issues triggered for me with rare case of particle system usage (the current one)...So like.. native functionality.

 

To repeat. I do not use Jobs at all. Zero. This is built into a variety of Unity packages when you're running the game with higher framerates.

 

I found that reducing the framerate in the loading scenes (using loading async in my game) to 60 fixed it for me and some players, but if may need to be reduced to 30fps too as some players still get it on lower-spec machines.
It might have to do with a factor of the screen refreshrate (ie maybe setting it to half of the Vsync refresh rate)
Still a very annoying bug and it's been an issue for a very long time

 

Giving the ceremonial bump to this issue as it became a bigger pain point for me today. It's not a big show stopper crash, but if I want to debug/work on any of my own code's warnings I have to restart the unity editor after each exit from play mode.
Really hope a solution gets backported to 2019 LTS at least.

 

Are you using any burst or job stuff @zachlindblad? I've found sometimes I miss a deallocation on something and have this issue.

 

Yeah, quite a bit, and I mean jobs->leak detection is incredibly useful compared to my previous experiences debugging leaks in straight c/c++. However even after I fix all leaks (unless there's leaks in my code the leak detection can't catch in which case that's a different, larger issue), even when I'm not making any code changes just doing level design or testing, the torrent of warnings persists.

Also I'm tentatively sure it's not a real leak, as I run unity all day and have kept an eye on its ram use in the past without any noticeable bloat over time.

I assume it's related to the combine dependencies issue iamarugin linked to, I've been using the method a lot in my project so far. I could try removing all of them, but it sounds like it's not the only cause of the issue (people recently reporting it happening despite not using jobs, from particle systems, higher frame rates, etc.), and with no ability to check a stack trace I'm hesitant to take a significant overhaul a lot of my most fragile complicated systems for the chance of fixing a warning that seems to be called incorrectly.

It's not a show stopper, not a end of the world issue, but just a constant underlying reality that I can never enable my warnings log channel, and it always sits at 999+ after my first run.

 

It seems to just assume any job is a leak if it lasts longer than 4 frames, which is of course a terrible assumption.

 

I mean if they made this as a design choice I could accept it, but the real blocker issues for me are:
1. The error seems to be thrown continually once it starts, rather than once for the job that has leaked, making the warning channel unusable.
2. The error seems to be caused (in some cases) from internal unity systems, though I can't 100% verify because...
3. With no stack traces, there is no way to debug it even if it came from your code.

 

If your frame rate is too high, then internal Unity processes will throw this error. Try putting on vsync.

 

I have on Vsync, this problem has been happening for me for almost 6 months now. I am guessing it could be due to the combineDependency issue, but given this warning can be caused by a variety of issues, and the warning its self has no stack trace/job info in it, there's no way to verify if that's actually the cause.

 

I'm seeing this quite a lot in a project that is not using any of the Jobs-stuff (yet). It's a VR project, so it's running at 90 FPS. But there are also ridiculous warnings in some of the UI code that spam the log.

In general, Unity has become a terrible mess and I really wish there was an easy way out.

 

Its complete nonsense spewing warnings for longer-than-4-frames jobs because its exactly the idea to spread processing across frames o ease FPS.

 

Well, you are supposed to use persistant allocation if you want to do it more than 4 frames. The issue here is the spamming of the log even when people are not using any NativeArrays in their own code. It is hidden somewhere in Unity's backend.

 

-outdated-

 

@tertle I meant Unity is using this in their own code, so it is hidden from the programmer. A lot of these complaints are from people not even using any NativeArray. The fix is to lock the frame rate to 60 and that fixes it for them.

 

Either Allocator option causes the warning in 2018 afaik.

 

@eduardo-pons The Allocator.Persistant should never throw this error. It is only Allocator.TempJob that will throw this error. You can leave Allocator.Persistant in memory forever with no errors. If you are still getting that error and using Allocator.Persistant everywhere it is probably an issue with internal Unity Jobs.

 

Thank you. This solved the problem for me.

 

I'm developing a game with Unity 2019.1.f1 and some of my users are experiencing crashes at a certain point. All of them have logs that are spamming "JobTempAlloc has allocations that are more than 4 frames old" and related messages.

None of my code is using the job system, but it's possible some of my packages or plugins are. However, I have no way of telling which one(s) it is. How can I do this?

How exactly can I "enable the define: TLA_DEBUG_STACK_LEAK in ThreadsafeLinearAllocator.cpp", and exactly where is this magical CPP file?

 

@k76 Unity is using a lot of jobs under the hood. Search for Allocation.TempJob in your plugins to see if any of them are using them.

This error can pop up when the game has too high a frame rate. Try enabling V-sync by default. This means less frames are rendered and therefore the error won't happen.

Unfortunately Unity hasn't disabled this spam error for some reason. I am not sure why.