coroutine from previous scene still appears in profiler

Hi all,

I'm trying to get to the bottom of a little lag issue in my game and so I was looking at the profiler and I noticed something quite strange. A coroutine from the previous scene appears to still be running every frame somehow. The object that the script is on is NOT set to DontDestroyOnLoad, and I can't see any references to it in the new scene, but every frame in the profiler I see

MainMenuUI.SetupCoroutine() [Coroutine: InvokeMoveNext]

So just to be clear, MainMenuUI is not placed on any objects in the new scene that is loaded.

At the point where I am getting lag, this call jumps to the top of the profiler list, with 34% of CPU usage. The bulk of that appears to caused by a 25k GC allocation.

Another strange thing is that the point that the lag occurs, code that was just called is appearing as children of the SetupCoroutine line above in the profiler.

Can anyone suggest why this might be happening? In the MainMenuUI I do load the new scene with this:

Code (CSharp):

1. IEnumerator LoadLevelWithBar (string sceneName){
2. async = SceneManager.LoadSceneAsync(sceneName);
3. while (!async.isDone)
4. {
5. loadingBar.value = Mathf.Max(0.04f, async.progress);
6. yield return null;
7. }
8. }

But I would assume that as soon as isDone is true, and the new scene appears, that the coroutine would stuff running.

Thanks in advance
Bill

 

We recently submitted a bug report (Case # 852360) with CustomYieldInstruction's (https://docs.unity3d.com/ScriptReference/CustomYieldInstruction.html) not stopping properly by reference to a coroutine using StopCoroutine(IEnumerator). They were only stopping using StopAllCoroutines().

This problem meant that coroutines were constantly evaluating their yield instruction's keepWaiting property (https://docs.unity3d.com/ScriptReference/CustomYieldInstruction-keepWaiting.html) even though they were supposed to be stopped. So, if keepWaiting does anything with a side effect or costly on cpu/memory, or we use lots of them, then things grind to a halt.

Your problem could be related to this if there's a more general coroutine problem under the hood. We haven't noticed anything like this, but we're currently not using async scene loading like your example.

Perhaps try dropping a Debug.Log() statement in that loop that prints when it's running, and try calling a StopAllCoroutines() on the object you're running the coroutine on when it's destroyed and see if the coroutine still runs after the scene has loaded. If you can trap it then make a test project and submit a bug report (and maybe reference our case # 852360 if you think it's related.)

 

thanks for the reply! I just noticed that it doesn't appear when the deep profiler is activated, so I'm guessing it's just a bug with the profiler but I'll post back here if I discover anything else.

Thanks again.

 

I'm seeing this exact issue as well on Unity 5.4.2f2.

Did you find out if this was this a problem with the profiler? It's causing around 100+ MB of garbage between scene loads for us at the moment.

Turning on "Deep Profile" makes these garbage allocations go away however which leads me to believe that this is a problem with the profiler instead.

In the attached image is an example of how large this GC Alloc is.

I've learnt that commenting out/disabling the coroutines that show up like this in the profiler just moves the GC Alloc to display under another coroutines name. Some might be still in the scene but as you stated in your original post, some of them might have actually been destroyed long ago.

 

I have the same problem in Unity 2017.3

 

same problem in Unity 2017.4