Editor Crash From Adding Localtoworld

I'm not sure how helpful this is but when I add a LocalToWorld to an entity the editor is crashing.

I am calling the system that adds the LocalToWorld component from a monobehaviour fixed update. I'm not sure if that could interfere with the hybrid renderer in some way?

Any further debugging ideas are welcome as I try to figure out what's going on.

Unity 2019.1.0 b10 and all the latest DOTS packages.

Code (CSharp):

1. Receiving unhandled NULL exception
2. Obtained 9 stack frames.
3. #0  0x0000010d24507a in void PrepareBatchRendererGroupNodes<true>(RenderNodeQueuePrepareThreadContext&)
4. #1  0x0000010d2f2a1e in ExecuteRenderQueueJob(RenderNodeQueuePrepareContext*, unsigned int)
5. #2  0x0000010d9f7a0c in JobQueue::Exec(JobInfo*, long long, int)
6. #3  0x0000010d9f82a4 in JobQueue::ProcessJobs(JobQueue::ThreadInfo*, void*)
7. #4  0x0000010d9f72d5 in JobQueue::WorkLoop(void*)
8. #5  0x0000010de35dff in Thread::RunThreadWrapper(void*)
9. #6  0x007fff6c6d633d in _pthread_body
10. #7  0x007fff6c6d92a7 in _pthread_start
11. #8  0x007fff6c6d5425 in thread_start

 

It might be that you add LocalToWorld component during RenderSystem is running which cause Chunk shifting while job is running on it.
If it not necessary to update in fixed update then queue that entity change to EndFrameCommandBatch. Otherwise move the code "that adds the LocalToWorld" to a job create new JobHandle with dependency is whatever system run nextframe.

 

Shouldn't be a problem it should wait for all jobs automatically.

I don't think adding LocalToWorld is the problem but rendering the entity is. Without LocalToWorld it wasn't rendered.
* Try adding LocalToWorld right at the beginning and check if that fails too.
* Deactivate Burst. That might trigger an exception that is showing you the actual problem instead of crashing.

 

Oh, hey, I thought it was just me who had this problem!

Upgrading to ECS preview 30 started giving me crashes whenever I let the render system run. Stacktrace looks similar.

Code (CSharp):

1. 0x00007FF77E3F5A63 (Unity) PrepareBatchRendererGroupNodes<1>
2. 0x00007FF77E49E649 (Unity) ExecuteRenderQueue
3. 0x00007FF77E49E700 (Unity) ExecuteRenderQueueJob
4. 0x00007FF77EAC15B4 (Unity) JobQueue::Exec
5. 0x00007FF77EAC3814 (Unity) JobQueue::ProcessJobs
6. 0x00007FF77EAC7EE8 (Unity) JobQueue::WorkLoop
7. 0x00007FF77EE15857 (Unity) Thread::RunThreadWrapper
8. 0x00007FF87FF63DC4 (KERNEL32) BaseThreadInitThunk
9. 0x00007FF880C83691 (ntdll) RtlUserThreadStart

Haven't tried to pin it down to a smallest reproducible case yet, though. Kind of assuming a new project won't have the same issue anyway...

Edit: Disabling burst, same behavior

 

Thanks for the suggestions, guys.

Adding just the LocalToWorld component in its own job has fixed the issue. However, shouldn't adding the component on the main thread and calling inputDeps.Complete () afterward be equivalent (not that you'd necessarily want to do it that way)?

I'm still not sure I understand why the job has worked and adding the component on the main thread has failed in this case. I would expect the main thread to stall, not crash.

Am I missing some gotchas of using command buffer on the main thread?

As an aside, I originally added this component on the main thread as the entity it is attached to has a shared component, which AFAIK can't be added in a job.

 

Hah, that just makes me more confused about my case. I don't even call update on the presentation group once before applying my LocalToWorld component (via ConvertScene).

Edit: Okay, well, apparently if you have two PresentationSystemGroups in two Worlds, even if you're only updating one, you get this crash. Removing the unused presentation group fixed it.

 

Good to know @Piefayth, thanks for posting. I have two worlds and may have been doing something similar. It feels like I've fixed it by accident at the moment so a bit more investigation might be warranted.

 

Well, turns out I was wrong anyway. The change I added had a mistake that created the illusion of fixing the crash. So I fleshed out my minimal reproduction some more, and the thing that appears to have actually fixed it perplexes me quite a bit.

Here is the NON WORKING code. It loads a scene, then converts the contents into both the client and server world so they have the same map loaded (and coexist in a single unity instance).

Code (CSharp):

1.  
2. protected override void OnUpdate() {
3.     if (!loadedScene && !loadingScene) {
4.         bootstrap.StartCoroutine(LoadScene());
5.         loadingScene = true;
6.     }
7.  
8.     if (loadingScene && loadedScene) {
9.         Scene scene = SceneManager.GetSceneByName("DevelopScene");
10.        
11.         if (Settings.server) {
12.             DefaultWorldInitialization.Initialize(WorldKey.SERVER_WORLD.ToString(), false);
13.             Worlds.serverWorld = World.Active;
14.  
15.             GameObjectConversionUtility.ConvertScene(scene, default, Worlds.serverWorld);
16.         }
17.  
18.         if (Settings.client) {
19.             DefaultWorldInitialization.Initialize(WorldKey.CLIENT_WORLD.ToString(), false);
20.             Worlds.clientWorld = World.Active;
21.  
22.             GameObjectConversionUtility.ConvertScene(scene, default, Worlds.clientWorld);
23.         }
24.  
25.         SceneManager.UnloadSceneAsync("DevelopScene");
26.         this.Enabled = false;
27.  
28.         bootstrap.StartGameLoop();
29.     }
30. }
31.  

The change that actually fixed it was changing the order of world initialization. I have *no idea* why this would be the case. Here is the segment I changed to stop the crash.

Code (CSharp):

1.  
2. //  note order
3. if (Settings.client) {
4.     DefaultWorldInitialization.Initialize(WorldKey.CLIENT_WORLD.ToString(), false);
5.     Worlds.clientWorld = World.Active;
6.  
7.     GameObjectConversionUtility.ConvertScene(scene, default, Worlds.clientWorld);
8. }
9.  
10. if (Settings.server) {
11.     DefaultWorldInitialization.Initialize(WorldKey.SERVER_WORLD.ToString(), false);
12.     Worlds.serverWorld = World.Active;
13.  
14.     GameObjectConversionUtility.ConvertScene(scene, default, Worlds.serverWorld);
15. }
16.  

I wanted to try to reduce this to the minimal reproducible case, but just can't get under the hood enough to figure out exactly what goes wrong.

 

I just saw your blog post that you linked in another thread and removing all PresentationSystemGroup from my sim world (equivalent to server world in a way) has fixed the Unity editor crash

This crash happens, for my setup at least, if you have 2 worlds with 2 PresentationSystemGroups and render capable entities in both worlds.