Reloading domain starts and never finishes even when disabled

News & General Discussion
1

This issue has made Unity completely unusable. Every time I change my code it forces me to restart Unity.


I have already tried restarting my computer and deleting all the temp files.
I am on Unity 2023.1.0b19.

2

First, upgrade to a non-beta build. 2023.1 is officially available for a couple weeks now.

Next, check if there is anything in the editor.log.

Lastly, check all things that run during domain reload, specifically AssemblyReloadEvents and InitializeOnLoad and something. I once managed to get domain reload in an endless cycle by modifying a script during assembly reload which … I think you can guess what that does. :wink:

3

I updated to the latest Unity build, thanks for letting me know there’s a new version.
It still didn’t work so I checked the editor.log and there’s just nothing. It says “Begin MonoManager ReloadAssembly” and then it never actually does anything.
I’ll attach it so you can see what I mean. (changed to .txt so I can upload it)

9122152–1265884–Editor.log.txt (56.9 KB)

4

It turns out that unity waits for threads to finish before starting to reload the assemblies. I had a thread that wasn’t stopping when it was supposed to.

5

Same on 2022.3.24.
it was just a common update on Script then stucks on infinity reloading Domain

6

I know Unity team is aiming to detect the CAUSE of issue BUT, they could (please) implement a way around for when it’s really stuck forever: Just put a button in the “Busy” message to abort the operation and start again. Or add a module that every 2 seconds it checks wheater it’s “reloading domain” without progress, to abort operation and start again.

I’m getting this bug like 10 times every day, it’s becoming REALLY annoying. As I said, I know the freezing is a sympthom of something else failing, but I’m proposing here that you find a way of, once freezed, to UNFREEZE it, unstuck it.

Our heads shouldn’t hurt, but when it does, we have aspirins.

7

When in the middle of a domain reload, you can’t just stop it. It would likely mean parts of the domain (the executing code) is new and others are old - that would lead to all sorts of issues.

Issues like these really need to be analyzed on the target system. It’s typically not something Unity can fix but rather something within the project that causes this behaviour. See above where an ongoing Thread caused it to hang.

So divide and conquer. Remove or change things until the issue goes away. Source control will help find a state where the project still worked correctly, and any change following that might be the root cause or at least connected to it.

8

I’m getting those infinite reloads surpsisingly often lately. Just today I had it for, like, 70% of all script changes, but it was fine yesterday. I don’t think I did any big changes since then, but here I am.
Before I had one project that had this issue 100% of times on each recompilation.

I wish there was some way to debug this at least.

9

Actually…
I decided to check that old project and found the reason. Basically, it was a recursion with SerializeReference. But the thing is - it was a recursion with a private field. If you mark it NonSerialized explicitly - it stops freezing. Also, it freeze only if there was a scene with that component opened at the time of compilation.

Edit: And yes, auto-properties also cause this. Need to add [field:NonSerialized] to those

Reported:

10

It was taking 5+ minutes on Unity 6.3 project upgrade. Strange issue.

Later, I found the issue. It was the “Entity” package for me. Removed & problem solved.

11

Hi!
Going through the replies on this thread I think there’s a few things we can do to help.

they could (please) implement a way around for when it’s really stuck forever: Just put a button in the “Busy” message to abort the operation and start again.

We can’t just stop a Domain Reload, unfortunately. During domain reload, C# threads get shut down, data gets backed up for when the next domain comes up, the C# compiler is invoked too, so there are a number of reasons why that’s just not feasible.

However, to address your point about freezing being a symptom of something else, there is a Diagnostic tool that you can use which will at least tell you what something is getting stuck on:

If you go to Preferences- > Diagnostics → Core → MonoLogLevel, and set it to Warning then you should be able to see in the Editor log what is stalling the domain reload:

image
image815Ă—680 82.7 KB

We had an example in another thread where a C# finalizer was responsible for deadlocking the domain reload.

The log line to look for would be something like:

Mono : warning : Domain Unload is waiting for 1 threads to end. Thread IDs are:
Mono : warning : Thread[0]: (214403)
Mono : warning :
"Thread Pool Worker"  at <unknown> <0xffffffff>
 at (wrapper managed-to-native) ExamplePlugin.Hang () [0x00011] in <a57ef81576e743868f565b542410dbe3>:0
 at ExamplePlugin/<>c.<RunLongRunningTaskAsync>b__2_0 () [0x00001] in /Users/javier/Projects/AssetPipeline/ProcessHang/Assets/Hang02/HangAsync.cs:19
 at System.Threading.Tasks.Task`1<int>.InnerInvoke () [0x00011] in <4cd4c67de2d54e76993cd773cd169e46>:0
 at System.Threading.Tasks.Task.Execute () [0x00001] in <4cd4c67de2d54e76993cd773cd169e46>:0
 at System.Threading.Tasks.Task.ExecutionContextCallback (object) [0x00006] in <4cd4c67de2d54e76993cd773cd169e46>:0
 at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00073] in <4cd4c67de2d54e76993cd773cd169e46>:0
 at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00004] in <4cd4c67de2d54e76993cd773cd169e46>:0
...

If the Editor is stuck forever, you can head on over to this other thread where we have a little how-to on debugging Editor stalls: Debugging Editor freezes and hangs [Windows Only]

Basically, it was a recursion with SerializeReference. But the thing is - it was a recursion with a private field.

As for the case brought up by @GamerXP, we have recently added a number of Rosyln Analyzer rules to catch exactly this sort of thing. In this case, these look to be the relevant rules that could give you a heads up about this:

Hope this helps!