Godot crashes the entire macOS desktop

[SommerEngineering]

Tested versions

• Godot 4.2.1-stable.mono

System information

Godot v4.2.1.stable.mono - macOS 14.2.1 - GLES3 (Compatibility) - Apple M2 Pro - Apple M2 Pro (12 Threads)

Issue description

I have started work on a new game concept. I used Godot 4.2.1 together with .NET 8 under macOS. As editor, I use Rider with the Godot plugin from JetBrains.

After creating the Godot project, I spent a few hours working on my mockup. I didn't need any scripts for this, so I only worked with the Godot editor. This all went very well.

When I was satisfied with the mockup and I wanted to implement my first C# scripts, the problem occurred. After a few lines of code, the entire macOS desktop froze. When I only work with Rider and .NET 8, this doesn't happen. After a restart, the same thing happened again within a few minutes.

In the macOS logs, I can see that the macOS Windows server crashes first. The reason is, that another process is no longer alive:

Namespace WATCHDOG, Code 1 monitoring timed out for service
(1 monitored services unresponsive):
checkin with service: WindowServer (0 induced crashes) returned
not alive with context: is_alive_func returned unhealthy

Next, the Godot processes crash. I assume that one Godot process is for the editor, and the other is for the language server for Rider. The editor process always crashes in thread 44, the language server always crashes in thread 0.

(I had one Godot process with parent process=launchd and another with parent process=rider)

Here are the details for thread 44 (Godot process for editor, i.e. main Godot window):

0   libsystem_kernel.dylib        	       0x188aba0dc __pthread_kill + 8
1   libsystem_pthread.dylib       	       0x188af1cc0 pthread_kill + 288
2   libsystem_c.dylib             	       0x1889fdad4 __abort + 136
3   libsystem_c.dylib             	       0x1889fda4c abort + 192
4   libc++abi.dylib               	       0x188aa9070 abort_message + 132
5   libc++abi.dylib               	       0x188a99110 demangling_terminate_handler() + 320
6   libobjc.A.dylib               	       0x18873f99c _objc_terminate() + 160
7   libc++abi.dylib               	       0x188aa8434 std::__terminate(void (*)()) + 16
8   libc++abi.dylib               	       0x188aab520 __cxxabiv1::failed_throw(__cxxabiv1::__cxa_exception*) + 88
9   libc++abi.dylib               	       0x188aab464 __cxa_throw + 308
10  libc++.1.dylib                	       0x188a276b8 std::__1::__throw_system_error(int, char const*) + 100
11  libc++.1.dylib                	       0x188a1c4ac std::__1::recursive_mutex::lock() + 40
12  Godot                         	       0x108592ae4 0x104800000 + 64563940
13  Godot                         	       0x10852daec 0x104800000 + 64150252
14  Godot                         	       0x10852cc70 0x104800000 + 64146544
15  libsystem_c.dylib             	       0x1889adf98 __cxa_finalize_ranges + 476
16  libsystem_c.dylib             	       0x1889add20 exit + 44
17  libcoreclr.dylib              	       0x11433d7a0 PROCEndProcess(void*, unsigned int, int) + 416
18  libcoreclr.dylib              	       0x11433d5fc ExitProcess + 188
19  libcoreclr.dylib              	       0x114483be4 SafeExitProcess(unsigned int, ShutdownCompleteAction) + 320
20  libcoreclr.dylib              	       0x1143388e8 CorUnix::TerminationRequestHandlingRoutine(void*) + 28
21  libcoreclr.dylib              	       0x114341b00 CorUnix::CPalThread::ThreadEntry(void*) + 380
22  libsystem_pthread.dylib       	       0x188af2034 _pthread_start + 136
23  libsystem_pthread.dylib       	       0x188aece3c thread_start + 8

Here are the details for thread 0 (Godot process for language server for Rider):

0   libsystem_kernel.dylib        	       0x18954e0dc __pthread_kill + 8
1   libsystem_pthread.dylib       	       0x189585cc0 pthread_kill + 288
2   libsystem_c.dylib             	       0x189491ad4 __abort + 136
3   libsystem_c.dylib             	       0x189491a4c abort + 192
4   libc++abi.dylib               	       0x18953d070 abort_message + 132
5   libc++abi.dylib               	       0x18952d12c demangling_terminate_handler() + 348
6   libobjc.A.dylib               	       0x1891d398c _objc_terminate() + 144
7   libc++abi.dylib               	       0x18953c434 std::__terminate(void (*)()) + 16
8   libc++abi.dylib               	       0x18953f7d0 __cxa_rethrow + 204
9   libobjc.A.dylib               	       0x1891ed660 objc_exception_rethrow + 44
10  AppKit                        	       0x18dab3f20 -[NSCGLSurface flushRect:] + 1748
11  AppKit                        	       0x18dab3794 NSCGLSurfaceFlush + 132
12  GLEngine                      	       0x1f1e78338 glSwap_Exec + 244
13  OpenGL                        	       0x1f1c763b0 CGLFlushDrawable + 64
14  AppKit                        	       0x18d0ecae8 -[NSOpenGLContext flushBuffer] + 28
15  Godot                         	       0x105d40158 0x102ac0000 + 52953432
16  Godot                         	       0x105d9e97c 0x102ac0000 + 53340540
17  Godot                         	       0x103249e2c 0x102ac0000 + 7904812
18  Godot                         	       0x1031f69a4 0x102ac0000 + 7563684
19  Godot                         	       0x103227e84 0x102ac0000 + 7765636
20  dyld                          	       0x1892050e0 start + 2360

Important to know: This stack trace is always identical when the issue occurs. Even after a restart. So obviously, apart from the memory addresses.

Steps to reproduce

• Add any nodes to the scene. I had only used control nodes.
• Add a new C# script to a node and open it in Rider.
• Start writing C# code. I suspect that it happens when you access Godot functions, which then require the language server or at least communication with the Godot process. But this is just a guess.

Minimal reproduction project (MRP)

I don't currently have an MRP. I had really just started with my C# script, it was just a few lines of code. I assume that it is not due to the code itself. The scripts also ran without any problems in the game.

This is what my first script looked like at the time:

using Godot;

public partial class Columns : HBoxContainer
{
	// Called when the node enters the scene tree for the first time.
	public override void _Ready()
	{
		this.Resized += this.OnResized;
	}

	private void OnResized()
	{
		var width = this.Size.X;
		var height = this.Size.Y;
		var isPortrait = height > width;
		var isLandscape = width > height;
	}

	// Called every frame. 'delta' is the elapsed time since the previous frame.
	public override void _Process(double delta)
	{
	}
}

I was there and wanted to continue writing the script. You can see that the two variables isPortrait and isLandscape are not used. Due to the system crash, I could not continue here.

I then worked on a second script that looked similar:

using Godot;

public partial class Image : TextureRect
{
	private Control leftSide;
	
	public override void _Ready()
	{
		this.leftSide = this.GetNode<Control>("%Left");
		this.Resized += this.OnResized;
	}

	private void OnResized()
	{
		const int initialWindowWidth = 1280;
		var windowWidth = this.Size.X;
		var windowHeight = this.Size.Y;
		
		if(windowWidth > windowHeight)
		{
			this.ExpandMode = ExpandModeEnum.IgnoreSize;
			this.StretchMode = StretchModeEnum.KeepAspect;
			this.leftSide.SizeFlagsStretchRatio = 2;
		}
		else
		{
			this.ExpandMode = ExpandModeEnum.IgnoreSize;
			this.StretchMode = StretchModeEnum.KeepAspectCovered;
			
			const float factor = 0.02f;
			var updatedRatio = (initialWindowWidth - windowWidth) * factor;
			updatedRatio = updatedRatio switch
			{
				< 0.0f => 2f,
				0f => 2f,
				> 20f => 20f,
				
				_ => updatedRatio
			};
			
			this.leftSide.SizeFlagsStretchRatio = updatedRatio;
		}
	}

	// Called every frame. 'delta' is the elapsed time since the previous frame.
	public override void _Process(double delta)
	{
	}
}

This script is also unfinished. Due to these crashes, I am currently unable to work with Godot under macOS 🙁.

[SommerEngineering]

I just read about the OpenGL issues with macOS in issue #85619. Possibly, my problem is also related to this because my Godot project uses the OpenGL renderer (compatibility) as well. I will switch to the mobile renderer, test it again in the following days, and then provide feedback 🙂.

[lostminds]

I've been working a lot with Godot 4.2.1 (non-mono version) using the Compatibility render on a macOS 14.2.1 - Apple M2 Pro (so, very similar) but I haven't experienced these issues. I am however non using the mono-version of Godot and not using C# or any external script editors.

For the compatibility renderer openGL driver, are you using the ANGLE one or the OpenGL3 one? You can set it in the project settings rendering/gl_compatibility/driver in case the issue is related to the ANGLE-driver.

[SommerEngineering]

@lostminds Exactly, when I created my mockup in Godot at the beginning, I had no problems either. The issues only started when I created and edited C# scripts 🤷‍♂️. Oh, I hadn't activated the advanced settings at all 🙈 . So I had the standard settings... driver = opengl3 and fallback to ANGLE = true.

[karljohannisson]

I'm on a Mac and my Godot 4.2.1 stable offical keeps crashing the whole desktop too. I'm using VSCode with GDScript outside of the Godot editor. The hardware is an M3 macbook air.

[Calinou]

@karljohannisson Are you using a C# build of Godot?

[karljohannisson]

@karljohannisson Are you using a C# build of Godot?

@Calinou I don't think so. I have just downloaded the latest stable 4.2.x version from the Godot website. Today I updated from 4.2.1 to v4.2.2.stable.official [15073af] and I'm still experiencing the same thing. Should I open a separate issue for this or do you think it's related?

Edit: I've noticed it seems to not crash when I move Godot out of my Applications directory and run it from outside instead.