SIGABRT in SceneTree::process_timers()

Godot Version

Godot Engine v4.6.2.stable.official.71f334935

Question

I started getting more or less random crashes for my game recently. The game process stops with SIGABRT and Godot shows no errors or other console output. I can usually reproduce after some minutes of playing. I think it happens at the end or start of some Tweens for moving nodes around, but not sure.

Below is the Mac crash report (Godot without symbols, sorry).

Only hint I see is that it stops in SceneTree::process_timers() called from SceneTree::physics_process(double).

-------------------------------------
Translated Report (Full Report Below)
-------------------------------------
Process:             Godot [88644]
Path:                /Applications/Godot_v4.6.2.app/Contents/MacOS/Godot
Identifier:          org.godotengine.godot
Version:             4.6.2 (4.6.2)
Code Type:           ARM-64 (Native)
Role:                Foreground
Parent Process:      launchd [1]
Coalition:           org.godotengine.godot [33458]
User ID:             501

Date/Time:           2026-04-12 20:35:18.8963 +0200
Launch Time:         2026-04-12 20:30:46.0649 +0200
Hardware Model:      Mac16,12
OS Version:          macOS 26.3 (25D125)
Release Type:        User

Crash Reporter Key:  3093DE2C-24F2-E5F2-6881-3628E4BAB6CC
Incident Identifier: BBDAF609-0138-4A9A-8A64-2F6FC9A216C7

Sleep/Wake UUID:       71D34217-386B-49B1-A80D-67C8FDEF00CB

Time Awake Since Boot: 360000 seconds
Time Since Wake:       15813 seconds

System Integrity Protection: enabled

Triggered by Thread: 0, Dispatch Queue: com.apple.main-thread

Exception Type:    EXC_BAD_ACCESS (SIGABRT)
Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000161
Exception Codes:   0x0000000000000001, 0x0000000000000161

Termination Reason:  Namespace SIGNAL, Code 6, Abort trap: 6
Terminating Process: Godot [88644]


VM Region Info: 0x161 is not in any region.  Bytes before following region: 4340579999
      REGION TYPE                    START - END         [ VSIZE] PRT/MAX SHRMOD  REGION DETAIL
      UNUSED SPACE AT START
--->  
      __TEXT                      102b80000-10bae8000    [143.4M] r-x/r-x SM=COW  /Applications/Godot_v4.6.2.app/Contents/MacOS/Godot

Application Specific Information:
abort() called


Thread 0 Crashed::  Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	       0x18a9595b0 __pthread_kill + 8
1   libsystem_pthread.dylib       	       0x18a993888 pthread_kill + 296
2   libsystem_c.dylib             	       0x18a898850 abort + 124
3   Godot                         	       0x10338d044 0x102b80000 + 8441924
4   libsystem_platform.dylib      	       0x18a99d764 _sigtramp + 56
5   Godot                         	       0x10591b698 SceneTree::process_timers(double, bool) + 152
6   Godot                         	       0x10591b0c0 SceneTree::physics_process(double) + 252
7   Godot                         	       0x103409f2c Main::iteration() + 564
8   Godot                         	       0x103386fec 0x102b80000 + 8417260
9   CoreFoundation                	       0x18aa31e58 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 36
10  CoreFoundation                	       0x18aa31d54 __CFRunLoopDoObservers + 648
11  CoreFoundation                	       0x18aa31400 __CFRunLoopRun + 924
12  CoreFoundation                	       0x18aaebf3c _CFRunLoopRunSpecificWithOptions + 532
13  HIToolbox                     	       0x19756d790 RunCurrentEventLoopInMode + 316
14  HIToolbox                     	       0x197570ab8 ReceiveNextEventCommon + 488
15  HIToolbox                     	       0x1976fab64 _BlockUntilNextEventMatchingListInMode + 48
16  AppKit                        	       0x18f34d014 _DPSBlockUntilNextEventMatchingListInMode + 236
17  AppKit                        	       0x18ee4ae48 _DPSNextEvent + 588
18  AppKit                        	       0x18f911e8c -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 688
19  AppKit                        	       0x18f911b98 -[NSApplication(NSEventRouting) nextEventMatchingMask:untilDate:inMode:dequeue:] + 72
20  AppKit                        	       0x18ee43780 -[NSApplication run] + 368
21  Godot                         	       0x1033e59e8 main + 924
22  dyld                          	       0x18a5c9d54 start + 7184

What can I do to debug this?

I know they seem random, but they’re not. Something is happening and you haven’t found the pattern yet. Computers only do what we tell them to do. The first thing to do is figure out how to reproduce the bug.

  • What were you doing just before the crash occurred?
  • How long is the game running when the game crashes?
  • Monitor the system. Are you running out of RAM?
  • When did the crashes start happening? What code have you added since they started? If you comment that code out, do the crashes stop?

Answering these questions and others like it are going to help you track down the problem. It’s important to understand that as the developer, you did something to make this happen. I’m not saying that to lay blame, just to say that this is the result of some action that is traceable. Even if ultimately it turns out that it’s some obscure Godot bug, it’s happening because you are using a feature that makes that bug possible. Taking a step back and saying, essentially, “What’s my part in this?” is the best way to track down how to reproduce it and then debug and fix it.

I’ll try to walk back the commits of the last days and pinpoint the problem more accurately.

I’ll also try to build Godot in debug mode and see if I cancan learn more about what’s going wrong under the hood.

1 Like

I’ve had ““random”” crashes too, because I turned on “Run on Separate Thread” in the project settings.

It was causing thread concurrency issues that were dependent on CPU state, so some days I had them, some days I did not, depending if I started Godot then Firefox or the opposite.

It’s not the same thing, but do check if you are interacting with Nodes that might be reserved by an other thread

1 Like

Turns out it was my fault after all :smiley:

I need to call RefCounted::reference() and ::unreference() manually at some points in my code (otherwise Godot releases instances when I still need them). I introduced a bug which caused an object to be unreferenced one too many times. So it gets released early but Godot Engine internally still held a reference. And when it tries to access this reference it crashes.

I managed to build Godot Engine with debug symbols and attach a debugger while running my game. But the issue was difficult to debug this way. The debugger stops the code in one place but the faulty dereference happened in another.

In the end I found the issue by recording videos of the playback and then studying closely what events happened immediately before the crash and looking for patterns.

Anyway, for good reasons Godot docs for RefCounted::unreference() have this to say:

Use this only if you really know what you are doing.

2 Likes