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

I tried searching my entire source for Allocation.TempJob but came up with no results.

That V-sync tip is interesting though. I'll have my users try that. Thanks!

 

Try searching Library/PackageCache and see what comes up.

 

He will find nothing except enum declaration with a simple summary. Allocation logic itself hidden in engine C++ side.

Read good research from Jackson Dustan (just one of many articles about memory allocators in Unity DOTS) https://www.jacksondunstan.com/articles/5406

 

I had the same problem in Unity 2019.4.10f1. The game crashed occasionally on loading (only in the build version). I was able to pinpoint it to async operations. I changed SceneManager.LoadSceneAsync to SceneManager.LoadScene and the problem is gone. The loading screen now stutters a bit but at least no more crashes.

 

Looks like I've joined the JobTempAlloc has allocations that are more than 4 frames old club, running on 2020.2.0b4.3200 Apple Silicon.

was starting to feel left out.

 

Happening to me as well. Searched entire solution as well as Library/PackageCache for Allocation.TempJob, nothing found. Also forced a 60 FPS with Application.targetFrameRate (and turning off V-Sync in quality settings). Nada. I'm on 2019.4.2f1.

 

+1 Pretty much a blank scene and project, still trying to narrow it down to cause, attempted many fixes mentioned, but i don't even have lights or shadows in, and they're off in quality settings, so.. XD

 

@jesusluvsyooh Have you tried limiting your frame rate? An empty scene will have an insanely fast frame rate which can cause the temp allocation warning.

 

Tried all 3 options Unity gives in quality area, without force setting one manually.

Edit: I've read all the forum pages and many other places ive found having similar problem, dating back to 2017
A few people have found solutions (such as vsync), but the cause seems to be different still for many I'l just keep trying and hopefully will post back if i find my way, to help others.

 

@jesusluvsyooh It definitely has to do with Unity's internal temp allocations. If the program runs too fast the internal code spits out these errors. And that code is managed by Unity, so I don't think we can do anything other than manually limiting Vsync.

 

@8bitgoose
Okay i solved it in my case
I had to manually set Application.targetFrameRate, as headless/server build clients don't use Unitys vsync quality settings. ( i had presumed they did )

 

@jesusluvsyooh Nice! Yeah that is the way, hack it till you make it.

 

@here

Overall by my research its a combination of factors.

Problem:
The core of the async API seems to measure their timings in "frames" rather than time.
If by some reason the framerate is too high due:

• Vsync On and maybe 100+ hz monitor
• Vsync Off and target frame rate well above 100+

In case of Vsync Off in scene changes or UI only moments the framerate will skyrocket and if there is any async operation happening the "4 frames" time limit will be hit in microsseconds triggering the warning.
In case of Vsync On by a close margin the asyncTimeSlice settings might not be enough to complete operations inside 4 vsynced frames.

Possible Solutions:

• Tweak the async time slice settings in player settings
• Either use vsync on or cap the target framerate to lower values all the time or during loads.
• Combine both approaches if its a super edge case

 

Having the same issue... I'm on 2019.4.4f1 and I don't use any jobs system. I really don't know what is causing it... It is my codes or something internal because the log isn't telling me the cause.

 

How did you nail it down to the cause being LoadSceneAsync? I'm using photon and Photon.LoadScene uses LoadSceneAsync internally. I can't change Photon's code as it might break something so idk how to go about this or even try if this is really the reason why the error is happening.

 

Check my info above.
Basically its related to FPS and LoadAsync of any nature.
Try forcing vsync off and targetFrameRate=30 or 20 before loading the scene.

 

This is happening on 2018.4.v32f1 for me, and from what I'm seeing in this forum discussion upgrading to 2019 or 2020 will only make the issue worse. If a Unity dev could give an update on this that would be great.

 

Nope, I'm on 2020.3 and no trace of the issue anymore. Not using Jobs or Burst though on this project.

 

Same

 

This warning spamming returns again. Unity 2020.3.5.

 

I don't think it ever went away.

The job system is useless. Just write your own multi-threaded code, same as you always would. Works just as well in Unity as in any other context.

 

This isn't actually related to Jobs, rather NativeArrays which are awesome. I hope Unity will give us the option to remove the log warning OR set the temp allocation lifetime which they said were arbitrary anyways.

 

When would ever see this warning when not using Jobs?

 

Also make sure you turn on VSync in the game window. For some reason, that fixes the internal JobTempAlloc warning.

 

@Stevens-R-Miller Unity uses Jobs within their background systems. So even if you don't use any jobs in your program, Unity has them run in the background.

@Kmsxkuse It's because with too high a frame rate, Unity will see that these temp allocations are being left behind due to your super high frame rate while stuff happens in the background. Turning on VSync means these jobs run in the background by the Unity never execute too fast.

@superpig Any chance we can get an option to turn this off soon? It can spam log files and make them huge and cause performance issues. Or an ability to change the TempJob allocation frame limit (for example increasing it to 1000 or something) just so that really fast computers won't have this warning in the future.

 

Ah, thanks! Didn't know that. (Loved your ScriptableObject presentation, by the way. That was a game-changer for me.)

Sure, but you don't see any warning arising from their use of it. Whatever they are doing with it, it doesn't get in your way. My problem with it is that I definitely have long-running worker threads that generate these warnings when I know for a fact that there is nothing wrong.

 

@Stevens-R-Miller Up until 2020 Unity, there were reports of people not using any jobs and still getting the spam. Seems like they have found the issue and closed that problem.

If you have longer running worker threads, definitely use Allocator.Persistent instead of Allocator.TempJob. No warnings that way. The Jobs system is a game changer for me, so glad they put it together.

 

So I was setting up some ECS Networking stuff and once again ran into this. You are gonna have a real bad time if you have a low server tick rate and a high frame rate. I think the user needs to be able to set the frame rate that TempJob allocation can be set to. Maybe a max of 144 frames or something. This error is often spamming the console log if someone's framerate is through the roof. Unfortunately in 10 years when computers are ultra fast, this error is gonna show up in lot of games with VSync turned off.

If you wanna super hacky limit your frame rate, just add this component to the world. Limits it immediately.

Code (CSharp):

1. using System.Collections;
2. using System.Collections.Generic;
3. using UnityEngine;
4.  
5. public class LimitFrameRate : MonoBehaviour
6. {
7.     // Start is called before the first frame update
8.     void Start()
9.     {
10.         Application.targetFrameRate = 144;
11.     }
12. }
13.  

 

Tweak the async time slice settings in player settings
It's Work! async Upload Time Slice = 8 and async Upload Buffer size = 16 Solved my “TLA_DEBUG_STACK_LEAK” problem，but too much loadAsync It will still cause jamming，But at least the number of times of asyncLoad until get stuck has increased。

 

I have long-running jobs, and I'm running into these warnings, presumably from internal Unity objects using TempJob allocation (since I'm not using TempJob myself).

I'm wondering if there's a bug filed to track the fix for these warnings?

 

still no fix for this in 4 years? ? ?

 

Oh it is fixed. At least the Unity side of things. If you still get this, you have a TempJob which lasts longer than 4 frames. Depending on your framerate that can be quite a short period of time

 

It's still happening for

NavMeshBuilder.UpdateNavMeshDataAsync

https://forum.unity.com/threads/upd...-schedulejobforeach-buildnavmeshinfo.1385553/

 

BUMP!

Getting this issue with NavMeshBuilder.UpdateNavMeshDataAsync as well.

 

I prepare Native datas and Schedule Jobs in Update, then call JobHandle.Complete and Dispose native datas in FixedUpdate. This warning appears in the editor when FPS exceeds 60, not in the build.

Now I have to replace all Allocator.TempJob with Allocator.Persistent, but I've heard that Persistent is slower than TempJob, should I use TempJob or Persistent?

 

For gods sake at least expose the frame count before the warning is emitted into Project settings.
We would set it to something like 20 and never come back to this issue.

 

If 4 rendering frames are executed between your fixed framerate you are going to get that warning. Interesting that it is not showing up in build. I wonder if they removed the warning in build versions of the game. You've never had that warning in a build? Can you check your frame rate in a build?

 

Yes, warning appears in the editor when FPS exceeds 60, not in the build.
Unity version: 2021.3.18f1c1
Burst version: 1.6.6

Editor:


Build:

 

I keep getting this bug from inside unity code still.
Usually happens during domain reload or recompiles.

I don't schedule any Jobs at these times.

 

Unity uses these jobs inside their own code. Probably why this message is showing up.

 

Yep, like I said - Unity Bug.

 

Haha of course right. I just skimmed your message instead of reading it. It's annoying that this problem has been in Unity for almost 5 years now. I understand the warning for not having those temp job allocations in too long, but we need to be able to set how long they can last I think.

 

I'm all for that. By that logic, almost everything should use Persistent instead of TempJob - it can happen that there might be high framerate and it won't finish under 4 frames.

The problem is that it's typically less than 4 frames, but with high framerate it's more than 4 frames and causes a lot of "false" positives. Biggest issue is that real problems hide among those false positives.

It's very annoying. To be 100% sure there's no problem, we have to run with '-diag-job-temp-memory-leak-validation' all the time.

And last thing, we don't have the choice always, for example NavMesh jobs use TempJob and there's a lot of warnings because of that - and I can't change allocators for Unity's internal jobs. (feel free to check attached log file, all the warnings there are caused by NavMesh. But I can't be sure unless I check with -diag-job... argument)

So, can you please acknowledge this issue and start discussion about possible solutions?

I'd be happy to have any of these as hotfix:

• configure warning frame count in ProjectSettings
• when logging warning, include name of the Job (easily distinguish real and false positives)

 

Seconded, +1, we need the second one of these, so much. Any Burst and Job logging needs to tell us what Job it was that stumbled.

(first suggestion is just closing one's eyes, but it would be ok, too, at least to keep the development workflow smooth)

 

Does this apply to NavMesh path calculations (if jobs are used) and to NavMesh modification / carving as well? Because I have different experience...it seems like it depends on complexity of the operation and might be affected by system load as well, making the duration highly non-deterministic.

 

I encountered another problem - because the performance is degraded due to the debug switch, the warning comes up much, much less frequently. Possibly masking some cases.

Anyway, I got to reproduce one - so is this a positive or false positive?

Seems like a true positive to me, and a Unity bug at that. To be precise, in our old and beloved f(r)iend
Unity.Scenes/SceneHeaderUtility.cs:298

Code (Boo):

1. headerLoadResult.SectionPaths = new UnsafeList<ResolvedSectionPath>(sectionCount, Allocator.TempJob);

Also related, ok, show us a warning we cannot remove from the console by clearing it, but please don't show it to us more than once.