ERROR: Caller thread can't call this function in this node (/root). Use call_deferred() or call_thread_group() instead.

[ColormaticStudios]

Godot version

4.2 stable

System information

Ubuntu bookworm, gnome 43

Issue description

When I try to open this project on my laptop, it crashes with the error:

     at: _editor_init (modules/gltf/register_types.cpp:63)
ERROR: Caller thread can't call this function in this node (/root). Use call_deferred() or call_thread_group() instead.
   at: propagate_notification (scene/main/node.cpp:2236)

================================================================
handle_crash: Program crashed with signal 4
Engine version: Godot Engine v4.2.stable.official (46dc277917a93cbf601bbcf0d27d00f6feeec0d5)
Dumping the backtrace. Please include this when reporting the bug to the project developer.
ERROR: FATAL: Index p_index = 1 is out of bounds (size() = 0).
   at: get (./core/templates/cowdata.h:158)

My laptop is a Lenovo Thinkpad T410 with 4GB of ram.

Steps to reproduce

Download the project mentioned before Open it

Minimal reproduction project

https://github.com/ColormaticStudios/quality-godot-first-person-2 (it's decently small)

[addmix]

Can you upload a minimal reproduction project that only has the issue at hand, and no unrelated code/scenes?

With such low memory on your computer, have you also checked that you are not running out of memory?

[bitsawer]

I can't reproduce any errors on Windows 10 with GTX 970, so possibly an OS or hardware related issue. Does using the OpenGL Compatibility renderer instead of Vulkan work?

The demo seems to work fine with no errors:

[akien-mga]

Can't reproduce either on Mageia 9, on an Intel Core i7-8705G with 16G memory.

@ColormaticStudios Can you reproduce the issue systematically using the steps you described? If so, could you share the full console logs? The excerpt you pasted seems cropped.

If you can compile Godot from source, you should also be able to get a more informative stacktrace for the crash. You would have to compile Godot with scons debug_symbols=yes to enable debug symbols.

[adamscott]

I just realized that I had the same error when reproducing https://github.com/godotengine/godot/issues/85664.

[ColormaticStudios]

The error log isn't cut, that's the only thing it outputs after system info

[adamscott]

85306 should fix this issue if everything goes well.

[scripturial]

The above mentioned patch was proposed to be included in 4.2.1 but it appears not to have been?

I am getting the exact same error, well I think it is, and it is unclear to me what is causing it.

This appears in the debugger editor window:

E 0:00:12:0479   propagate_notification: Caller thread can't call this function in this node (/root). Use call_deferred() or call_thread_group() instead.
  <C++ Error>    Condition "!is_accessible_from_caller_thread()" is true.
  <C++ Source>   scene/main/node.cpp:2236 @ propagate_notification()

And this appears in the console:

  ================================================================
  handle_crash: Program crashed with signal 11
  Engine version: Godot Engine v4.2.1.stable.official (b09f793f564a6c95dc76acc654b390e68441bd01)
  Dumping the backtrace. Please include this when reporting the bug to the project developer.

[AThousandShips]

It is in 4.2.1 https://github.com/godotengine/godot/commit/24a383e2ec937a63e5019a8b7533e9572b37b1c4, so something else must be causing it

[scripturial]

It is in 4.2.1 24a383e, so something else must be causing it

Because I don't know anything about the internals of Godot, Its not immediately clear to me why it would be a different bug. The fundamental underlying error is the same right?

Caller thread can't call this function in this node (/root). Use call_deferred() or call_thread_group() instead

There is some function deep inside the code for Godot that is upset about how it is being called, and, for lack of a better phrase, pooping its pants instead of reporting what's going on. Unfortunately the error manifests itself seemingly randomly and I have no clue what on earth may be triggering this.

I was trying to avoid creating a duplicate ticket because it felt like it might be the same issue, but if it's not, I should probably take your word for it and make a new ticket. But even then, because I have no idea what part of my code is triggering it, I don't even know where to begin to make a minimum project for this. (Im at bout 10,000 lines of gdscript for this one)

[hatemsh]

I'm having the same issue on Apple M1 Pro, Sonoma 14.4.1 It triggers seemingly randomly as well

[Etruscian]

I have it consistently triggering on my system on V4.2.2 mono, v4.3-dev3 mono (although the line at which the error occurs is different, namely node.cpp:2286 instead of node.cpp:2236 with both), and v4.3-beta1 mono (here, the line is node.cpp:2416). If I can assist with anything, please let me know!

[Shadow8472]

I'm landing here as well.

Godot V4.2.2-stable PopOS 22.04/KDE 5.24.7 (X11) Default project

$ ./Godot_v4.2.2-stable_linux.x86_64 
Godot Engine v4.2.2.stable.official.15073afe3 - https://godotengine.org
WARNING: XOpenIM failed
     at: DisplayServerX11 (platform/linuxbsd/x11/display_server_x11.cpp:5979)
Inconsistent value (1) for DRI_PRIME. Should be < 1 (GPU devices count). Using: 0
WARNING: XCreateIC couldn't create wd.xic
     at: _create_window (platform/linuxbsd/x11/display_server_x11.cpp:5603)
OpenGL API 4.5 (Core Profile) Mesa 24.0.3-1pop1~1711635559~22.04~7a9f319 - Compatibility - Using Device: Mesa - AMD BARTS (DRM 2.50.0 / 6.9.3-76060903-generic, LLVM 15.0.7)

Editing project: /home/shadow8472/Games/GodotProjects/GCcontrollerDemo
Godot Engine v4.2.2.stable.official.15073afe3 - https://godotengine.org
WARNING: XOpenIM failed
     at: DisplayServerX11 (platform/linuxbsd/x11/display_server_x11.cpp:5979)
WARNING: XCreateIC couldn't create wd.xic
     at: _create_window (platform/linuxbsd/x11/display_server_x11.cpp:5603)
Vulkan API 1.3.274 - Forward+ - Using Vulkan Device #0: Unknown - llvmpipe (LLVM 15.0.7, 256 bits)
<username>@<hostname>:~/<Godot/Directory/Path>$  
WARNING: Blend file import is enabled in the project settings, but no Blender path is configured in the editor settings. Blend files will not be imported.
     at: _editor_init (modules/gltf/register_types.cpp:63)
ERROR: Caller thread can't call this function in this node (/root). Use call_deferred() or call_thread_group() instead.
   at: propagate_notification (scene/main/node.cpp:2249)

================================================================
handle_crash: Program crashed with signal 11
Engine version: Godot Engine v4.2.2.stable.official (15073afe3856abd2aa1622492fe50026c7d63dc1)
Dumping the backtrace. Please include this when reporting the bug to the project developer.
[1] /lib/x86_64-linux-gnu/libc.so.6(+0x42520) [0x716139a42520] (??:0)
[2] llvm::CmpInst::Create(llvm::Instruction::OtherOps, llvm::CmpInst::Predicate, llvm::Value*, llvm::Value*, llvm::Twine const&, llvm::BasicBlock*) (??:0)
-- END OF BACKTRACE --
================================================================

Edit: I got a very similar log with the same error running Godot_v4.3-beta2_linux.x86_64

[akien-mga]

@Shadow8472 That's an unrelated issue, your crash is the llvmpipe software renderer crashing, which is a duplicate of #74172. Your GPU doesn't support Vulkan and so it's trying to use a (broken) software renderer.

[ogapo]

Seeing a similar crash in 4.3 semi-recent mainline build.

ERROR: Caller thread can't call this function in this node (/root). Use call_deferred() or call_thread_group() instead.
   at: propagate_notification (scene/main/node.cpp:2416)

================================================================
handle_crash: Program crashed with signal 11
Engine version: Godot Engine v4.3.beta.custom_build (f6e34865e7a9f192b8d195728a5b3cdf7444f3b2)
Dumping the backtrace. Please include this when reporting the bug to the project developer.
[1] 1   libsystem_platform.dylib            0x00000001978ab584 _sigtramp + 56
[2] 2   Metal                               0x00000001a1be75ac -[_MTLCommandBuffer dealloc] + 352
[3] 3   IOGPU                               0x00000001b68f4d30 -[IOGPUMetalCommandBuffer dealloc] + 212
[4] 4   AGXMetalG13X                        0x00000001eca9752c -[AGXG13XFamilyCommandBuffer dealloc] + 660
[5] 5   libsystem_blocks.dylib              0x000000019757717c _call_dispose_helpers_excp + 48
[6] 6   libsystem_blocks.dylib              0x0000000197576f48 _Block_release + 252
[7] 7   IOGPU                               0x00000001b68fe9ec IOGPUNotificationQueueDispatchAvailableCompletionNotifications + 136
[8] 8   IOGPU                               0x00000001b68feaf0 __IOGPUNotificationQueueSetDispatchQueue_block_invoke + 64
[9] 9   libdispatch.dylib                   0x00000001976ca4a8 _dispatch_client_callout4 + 20
[10] 10  libdispatch.dylib                   0x00000001976e6888 _dispatch_mach_msg_invoke + 468
[11] 11  libdispatch.dylib                   0x00000001976d1898 _dispatch_lane_serial_drain + 368
[12] 12  libdispatch.dylib                   0x00000001976e75d8 _dispatch_mach_invoke + 444
[13] 13  libdispatch.dylib                   0x00000001976d1898 _dispatch_lane_serial_drain + 368
[14] 14  libdispatch.dylib                   0x00000001976d2578 _dispatch_lane_invoke + 432
[15] 15  libdispatch.dylib                   0x00000001976d1898 _dispatch_lane_serial_drain + 368
[16] 16  libdispatch.dylib                   0x00000001976d2544 _dispatch_lane_invoke + 380
[17] 17  libdispatch.dylib                   0x00000001976dd2d0 _dispatch_root_queue_drain_deferred_wlh + 288
[18] 18  libdispatch.dylib                   0x00000001976dcb44 _dispatch_workloop_worker_thread + 404
[19] 19  libsystem_pthread.dylib             0x000000019787700c _pthread_wqthread + 288
[20] 20  libsystem_pthread.dylib             0x0000000197875d28 start_wqthread + 8
-- END OF BACKTRACE --
================================================================

[ogapo]

Actually looking into the source a little more I think the note about Caller thread may be a red herring. They appear to be a result of this code in the crash handler

    // Tell MainLoop about the crash. This can be handled by users too in Node.
    if (OS::get_singleton()->get_main_loop()) {
        OS::get_singleton()->get_main_loop()->notification(MainLoop::NOTIFICATION_CRASH);
    }

This would be unsound if the crash occurs in any thread other than main. It still doesn't say what the root cause of the crash is though (but it might be good to put a main thread check around that code to make bug reports better)