Lots of busy... Hold on.... etc?

Hello,

Same problem here, lots of "Hold on" pop up. Duration range : from 1min to 3min.
I cant really tell what triggers it, it's never happening at the same time.
I wonder if it has not something to do with big scene with lots of gameobjects.
I cant share my project as it's too big.

It's really anoying and killing productivity...

I dont think it comes from packages, as I have not really much.
Unity version : 2020.3.2f1 / URP

Here some screenshots :

 

Totally agree. "Hold on" Editor Application.update popups has made Unity unworkable. Happens mostly when opening and editing prefabs.

 

"Hold on" is like the motto of Unity. Years of waiting for "performance by default" and in the end an editor that cannot be used without long waiting.

Unity definitely needs its own battle royale to work with the engine and understand the users.

 

I deleted my library folder and re-imported the project and the long wait seem to be gone.
Note sure if that will stay for long (it seemed that the issue was getting worst overtime), will keep you informed if it's not the case.

 

No. A user said it happens mostly when opening prefab for him.
It's not what I'm seeing on my part. It's hard to pinpoint this bug to one thing, as it seem's to be pretty random.

I deleted my Library folder too, with no improvement (that I could tell).

 

Application.Quit is on hold now for 3 minutes when I want to quit a project. I have to force close with the task manager each time.

 

Not sure if i'm killing the correct one, but i killed the one marked in red (image bellow), the only one with -batch flag but it didn't work, Unity remained frozen for a couple more minutes.

I created of the bug reports, Case 1330504.

https://ibb.co/ctqJqSb

Update: After some more testing, killing that task actually improves the freezing time . On a small scene, the editor enters Play Mode instantly. On the more complex scene in the project, it reduces the enter play mode time to about 1 minute, usually takes around 5 or 6 minutes.

 

Hello jdrewsen,
Thank you for investigating this.

For me, killing the process (second line, with 26 CPU) completly fix the problem immediatly indeed.


Next time, I'll upload the AssetImportWorker*.log.

Can't provide reprocution steps as it seem's random.
Project is too big to be shared.

EDIT :
AssetImportWorker.log - while "hold on"
AssetImportWorker.log - after "hold on"

Hope it helps you.
Thank you.

 

So after 2 days since I deleted my library folder, the issue is coming back. I can confirm it slowly get worst, at first wait time was about 10sec, then the day after it was 1min, now today I need to wait around 5min.

@jdrewsen
I killed the process and it work! I have a workaround now, thanks for the help!

 

Hi @jdrewsen

This is good advice. It appears to have reduced the amount of "hold on" messages thus far.

But how do we stop Unity from re-enabling the executable? I've killed it twice already, but Unity keeps restarting it.

Is there an .exe we can safely delete?

 

Which build will this fix for process executable land on ?

 

From what i'm experience i think you have to killed it every time the editor freezes.

 

The workaround (killing the process) is working.

But it seems that this process is almost always running (when unity is open), even when there is no popup, and taking 25% of my CPU.

Is this going to be fixed in the 2020 LTS version ?

 

Unfortunately this work around does not solve all the issues. The most complex scene in my project still takes around 1 minute or 2 to enter play mode, it was 5/6 minutes before killing the task. Also in the editor itself i get a lot of Hold On messages from simple tasks, saving, open new scenes, sometimes just selecting a gameobject from the hierarchy. So this solution helps a bit on entering play mode, but the editor still have issues.

 

Thanks so much for the support on this issue @jdrewsen !

Also how can we reduce the amount of console window hosts and unity shader compilers? I wonder if this is affecting the "Not Responding" message from the editor

(Case 1331382)

 

Ok thanks for the confirmation.

 

Horrible! ... there is not one single full working Unity version from 2019.x upwards, where everything runs!
Just clicking into any window causes such popup now and then. Now for over 7minutes. Could write a book here meanwhile. pfffff......

 

Hi @jdrewsen
I sent you the asset import worker. LOG file in a private DM. Hope it helps

Enter play mode takes 6 minutes


Also just noticed that GI takes 4+ minutes (mind you I had 7 red errors in C# scripts too)

 

I'm currently using the workaround to kill the import process when the editor get stuck, it's a chore but it seem to work fine for now.

However, since some days the project is now extremely long to open:




I hope it's the same issue, but I don't see the import process when the project open.
It get worst every day (first it was 1 min, then 5, then 10, etc...)

Does anyone have an idea to fix that? Do I need to delete my library folder every week?

EDIT:
I removed the file "EditorEncounteredVariants" in shadercache and now project open instantly!

 

After deleting "EditorEncounteredVariants" Unity took 5 minutes to recompile the shaders. But you're right, after that, entering play mode is fast. Nice find! Hopefully this is it!

Unity 2021.1.4f1

EDIT: This has been working REALLY well. Not sure what deleting that file did. But entering PLAY is 5-10 seconds now. But I am getting this red error in the console.

EDIT2: I take it back... Lag is back. No idea what caused it. I'm going to try to go back to 2020.3.5 and see if things get better. Stuck with compiling shader.. I'm not using URP just the legacy shader. Maybe that's causing the issue?



@aleksandrk @jdrewsen

 

Hi @aleksandrk

(Case 1332782)

Unity crashed on me just now. First thing I did when the editor loaded, was press PLAY. And the editor crashed to desktop.

This was what the log showed me. Do you know what a SIGSEGV is? Might it have something to do with the shader compilation again?

Thanks!

Code (CSharp):

1.  
2. Launched and connected shader compiler UnityShaderCompiler.exe after 0.04 seconds
3. Launched and connected shader compiler UnityShaderCompiler.exe after 0.04 seconds
4. Setting up 8 worker threads for Enlighten.
5.   Thread -> id: 2ebc -> priority: 1
6.   Thread -> id: 82c -> priority: 1
7.   Thread -> id: 4388 -> priority: 1
8.   Thread -> id: 380c -> priority: 1
9.   Thread -> id: 1dbc -> priority: 1
10.   Thread -> id: 3c58 -> priority: 1
11.   Thread -> id: 3264 -> priority: 1
12.   Thread -> id: 3414 -> priority: 1
13. Stacktrace:
14.  
15. =================================================================
16. Got a SIGSEGV while executing native code. This usually indicates
17. a fatal error in the mono runtime or one of the native libraries
18. used by your application.
19. =================================================================
20.  
21. Received signal SIGSEGV
22. Stack trace:
23. 0x00007ff6bf26d361 (Unity) tlsf_memalign
24. 0x00007ff6bbb98497 (Unity) DynamicHeapAllocator::Allocate
25. 0x00007ff6bbb8d414 (Unity) DualThreadAllocator<DynamicHeapAllocator>::Allocate
26. 0x00007ff6bbb74a95 (Unity) MemoryManager::Allocate
27. 0x00007ff6bbb89e7c (Unity) malloc_internal
28. 0x00007ff6bc7235c7 (Unity) dynamic_array_detail::dynamic_array_data::resize_buffer
29. 0x00007ff6bb7740e8 (Unity) dynamic_array<RegisteredImporter,0>::resize_buffer_nocheck
30. 0x00007ff6bde3bff2 (Unity) dynamic_array<UndoPropertyModification,0>::assign
31. 0x00007ff6bde3274c (Unity) PropertyDiffUndoRecorder::Flush
32. 0x00007ff6bd792230 (Unity) Application::TickTimer
33. 0x00007ff6be0ff881 (Unity) MainMessageLoop
34. 0x00007ff6be1038c1 (Unity) WinMain
35. 0x00007ff6bff7eb56 (Unity) __scrt_common_main_seh
36. 0x00007fffd27f7034 (KERNEL32) BaseThreadInitThunk
37. 0x00007fffd3ac2651 (ntdll) RtlUserThreadStart
38.  
39.  

 

Hi @aleksandrk

Thanks for your help

Yep the bug report \ case should have the .DMP file and the .LOG files. Hope it helps!

I'm now crashing when trying to import packages into the editor. Should be : (Case 1332801)

 

@aleksandrk
UPDATE
I just noticed the scene size. HOW 450 MB ! !

This scene is just a few game objects, used to test new features.

What causes the scene file to get this big, so quickly? You can see the "baseSceneB" backup file is much smaller...


I guess due to the file size I was getting a lot of "Application.Tick" delays and the editor crashes. Also maybe the cause of the spikes in the profiler?

Does the editor know to DECREASE scene file sizes, after deleting the test game objects and scripts?


UPDATE END




What's causing ProfilerWindow.RepaintScene to spike like this?

 

Bug Report: Case 1332852

So I found something interesting.

Just for curiosity's sake, I started to delete game objects\ prefabs in the 450MB scene, to see what was taking up the file.

The UI Canvas prefab with a deep child hierarchy was 60MB, the most significant change.

I had several simple game objects\ prefabs remaining. (No deep child hierarchies) and Unity popped up a red error.

The file size dropped A LOT after that. Is the Undo Buffer being stored inside the .Unity file?

 

I don't want to be too negative here, but this is suposed to be a LTS version, it should mean stable.

It's kind of frustrating and really anoying to have to kill a process (that takes continuously 25 percent of my CPU) every 20 seconds to be able to use UNITY.

Any ETA for a bugfix ?

edit : I'm on 2020.3.2f1

 

Update
Hope this helps others

I managed to figure out the cause of the Unity Freezing, Crashing, Application.Tick, hold On etc etc.

If anyone is using Easy Save, try to delete the "Easy Save 3 manager" game object and create a new one. There was something going on there that caused the .unity scene file to bloat up in size and cause the editor to freeze \crash etc.
Update

How big is your scene file (.unity file) ... I wonder if you have the same situation as I did.

Does this happen to all your scenes? Or just 1?

For me the editor was freezing and crashing, every time I wanted to play. But I noticed it was only on the one scene.

After installing 2021, 2020.3, 2020.2, 2020.1, deleting \ reinstalling shaders, deleting library folders over and over, eventually I realized it had to do with the corrupted .unity file

I feel your pain. Keep troubleshooting!

I've updated to 2021.1.5f1 now and so far so good. fingers crossed

 

All 2020.3 and 2021.1 versions I tried are concerned by the issue. It gets stuck in Application.Reload when changing random stuff in the code.

Please do something.

 

Yes! That's right.... Unity just sucks today!

 

Hi. Having the same issue with 2020.3.4f1. I can play my scene once before it starts holding. Went to application.reloading when I pressed play but then again on going into preferences. I can't do anything. It holds forever and then have to force quit.

 

Same issue, a lot of "Hold on"...
Can't stand it, I have went back to 2019LTS

 

This is a joke, the team at the company update the project from 2019.4.5 to 2020.3.3 "LTS" because is supposed to be "stable". I lost almost half a week waiting for Unity to open (is taking almost 3 hours a day, sometimes 6 hours, it´s hell). what's the point of launching an LTS version that is not stable?, you are making me losing my time and possibly my job if I can't achieve the objectives because I need to wait hours and hours because of your engineer's mistakes. The project crashes just because I press CTRL+S to save the scene showing stupids windows that blocks all the application for minutes or hours, now I re-open de project and need to wait "any" number of hours to work, I hate this.

 

@Aras @jdrewsen I also have the same problems, explained on previous posts. One weird thing is that in my company only my computer suffers from the long hold on issues, the other computer that has the project does not. If it were a problem with a package it would affect both i assume?

 

Then I start playing mode in the editor -- progress bar with Application.Reload message appears and can take 2-4 minutes even if no changes were made in the scripts or scene. Occurs in the Unity 2020 and 2021 as well.
"Enter Play Mode Settings" with disabled "Reload Scene" doesn't help.
Is there a way to fix this or find the cause ?
Or should I get used to living with such lags ?
Or maybe there are some diagnostic tools to figure out what asset is taking so long to reload ?

 

The profiler (with deep profile enabled) is a good starting point.

 

@Gulliver i also used SuperLuminal to profile the Editor and send the data trough a bug report. With that info they were able to find one of the problems: Lots of busy... Hold on.... etc?

 

It's impossible to work.
On the PC with Ryzen 3950x, 64Gb RAM and SSD M.2 2280 -- I have to wait MINUTES for compiling and playing.
No explanations, no diagnostic, instead of improvements -- Unity editor become even worse.
Unity developers forces us to switch to the Unreal Engine ?

 

Have these issues as well, on several versions, even after refreshing the library. this issue continues on 2020 all versions. every hour I need to wait for 15 min till the hang widow is closed. Cant track the source of it. an unbelievable issue, for so long and no solution.

 

I have this issue on some of the projects.

Unity doesn't complete immediately some of the commands I give it for example save or clicking some button or similar. Instead it waits for minutes, showing the loading bar, then it completes the command.

looking at the task manager unity is sitting there at 5% doing nothing while the loading bar is on screen

This happens some of the time and sometime it works fine.

My theory is that unity doesn't detect the operating system input correctly. I see a lot of errors in the logs about the touch screen not initializing. The computer doesn't have a touch screen so why unity want to initialize the touch screen is a mystery.