EditorPlugins are being added to the editor during hot reload, not afterwards

[brezhnevtusks]

I have a main screen plugin with a window that has an exported OnEditor field referencing a Godot Resource. Whenever I reload the code in a project, errors are logged that have to do with that field. In one of the projects, those errors happen along with an editor crash (I wasn't able to establish why it crashed, though, only that both the error and the crash are caused by the same field).

The error looks like this (this is from the attached minimal project):

ERROR: /home/brezhnevtusks/.cargo/git/checkouts/gdext-067f4b88e7bd088f/0289637/godot-core/src/private.rs:455 - godot-rust function call failed: MainScreenPluginWindow::set_test_resource()
ERROR:  Reason: parameter #0 (core::option::Option<godot_core::obj::gd::Gd<on_editor_crash::main_screen_plugin::test_resource::TestResource>>) conversion
ERROR:  Source: cannot convert to class TestResource: Gd { id: -9223370132640683675, class: Resource }

Setting reloadable to false in the .gdextension file fixes the issue, so I assume it has to do with how hot reloading is handled for editor plugins? Or maybe my setup is wrong in some aspect that leads to those errors?

Attached is a minimal Godot project where I am able to consistently reproduce the issue. Just build, make changes to code while the Godot editor is open and you should see errors in the Output.

I am on Ubuntu 24.04.2 LTS, using Godot v4.4.1.stable.official [49a5bc7b6] and latest godot-rust master.

OnEditorCrash.zip

[TitanNano]

Without having ran the test project, my guess would be that the rust code is trying to cast the Resource to an TestResource before the TestResource Godot class has been re-registered.

[Bromeon]

I'm not sure if it's just being registered...

ERROR: Source: cannot convert to class TestResource: Gd { id: -9223370132640683675, class: Resource }

This indicates that we have a Gd<Resource> (with dynamic type Resource). This can of course not be converted to Gd<TestResource>, which is a class further down the hierarchy.

@brezhnevtusks any idea why you get a Resource instead of a TestResource at that point, could you see if you find out something with a debugger / printing? Is maybe some information lost across the reload?

[brezhnevtusks]

@Bromeon No idea. The field is declared as

#[export]
test_resource: OnEditor<Gd<TestResource>>,

Printing the resource class displays TestResource, not Resource. Running with backtrace doesn't produce anything besides the error I posted above.

Is there any other way I can test what's going on during reload? Anything to hook into?

Also, since this may not have been clear from my original message: this setup does work, in real projects I am able to get/set data on the resources referenced by main screen plugins. The only time it breaks (leading to errors and in case of one project crashes) is reloading. And it is fixed after an editor restart.

@TitanNano If you meant that the user code (not godot-rust code) in the test project casts from Resource to TestResource, then it does not. In fact, the struct that holds that reference doesn't have any logic. Simply having the field declaration seems to cause the error.

[Yarwin]

Is there any other way I can test what's going on during reload? Anything to hook into?

As far as I'm aware the only way is to compile debug build of Godot editor and poking around with lldb https://docs.godotengine.org/en/stable/contributing/development/compiling/index.html. I'll do it towards the end of the week.

[StatisMike]

Hmm, but as this is an @tool class, how should OnEditor field work there? I don't have experience with OnEditor yet, but as far as I understand it is a field that have to be set in editor before accessing the field.

As the EditorPlugin is meant to be running in editor, it is very likely that the field will be accessed before it is set in-editor, causing panic either way.

IMO the correct solution would be to use Option there - you need to be prepared for the field to be None, as it may be in some point whatever your use case will be.

[brezhnevtusks]

The OnEditor field is not declared in the plugin, it is declared in a class instantiated by the plugin. That class is a scene and has the value assigned, so Option doesn't seem necessary here. Also, I tried Option and it produces the same error.

The error we see is not caused by accessing the field on user's side, since the class in question doesn't run any logic.

[Yarwin]

Hmm, but as this is an @tool class, how should OnEditor field work there? I don't have experience with OnEditor yet, but as far as I understand it is a field that have to be set in editor before accessing the field.

As the EditorPlugin is meant to be running in editor, it is very likely that the field will be accessed before it is set in-editor, causing panic either way.

IMO the correct solution would be to use Option there - you need to be prepared for the field to be None, as it may be in some point whatever your use case will be.

It is up to plugin developer; a lot of godot plugins assume that given field can't be null and lack of it implies total failure (for example func_godot won't run without proper resources/configs). If your plugin uses process, physics_process or if there is any possibility that it could be run before user is able to fill the config then yeah, Option<…> is proper choice; if your plugin requires manual action to run and expects user to set all the required properties then OnEditor<…> should be valid choice.

(There are also cases in which whole instances are tool only to call one or two methods in the editor – to display some messages and whatnot. These cases are valid too.)

OnEditor<...> makes no sense for EditorPlugin though (you can't access it before it is initialized).

---

As for the actual bug – it is a bit hard to explain, so to make clear what is going on we will use following minimized version of the bug (which (doesn't) works both for Option and OnEditor).

minimal version of the bug

#[derive(GodotClass)]
#[class(tool, base = EditorPlugin, init)]
struct MainScreenPlugin {
    // var / property. Doesn't change anything, but illustrates that there is no memory leak or other SillyBehaviour.
    #[var]
    utility_screen: Option<Gd<MainScreenPluginWindow>>,
    base: Base<EditorPlugin>,
}


impl MainScreenPlugin {
    fn init_utility_screen(&mut self) {
        let utility_screen = ResourceLoader::singleton()
            .load("uid://bkhnrittppylb")
            .unwrap()
            .cast::<PackedScene>()
            .instantiate()
            .unwrap()
            .cast::<MainScreenPluginWindow>();

        EditorInterface::singleton()
            .get_editor_main_screen()
            .unwrap()
            .add_child(&utility_screen);

        self.utility_screen = Some(utility_screen);

        self.make_visible(false);
    }
}

#[godot_api]
impl IEditorPlugin for MainScreenPlugin {
    fn enter_tree(&mut self) {
        if self.utility_screen.is_none() {
            godot_print!("{:?}", self.utility_screen);
            self.init_utility_screen();
        }

        godot_print!("This text will be edited in-between runs.");

        let test_resource = ResourceLoader::singleton()
            .load("res://TestResource.tres")
            .unwrap();

        godot_print!("{test_resource}");
        let result = test_resource.clone().try_cast::<TestResource>();
        godot_print!("{:?}", result);

        let v = test_resource.to_variant();
        let this = self.to_gd();

        godot::task::spawn(async move {
            let _ = this.get_tree().unwrap().signals().process_frame().to_future().await;

            godot_print!("hello one frame later! I am {}", v.to::<Gd<TestResource>>());
        });
    }

    fn exit_tree(&mut self) {
    	// See if we exit tree properly.
        godot_print!("goodbay cruel world");
        if let Some(mut utility_screen) = self.utility_screen.take() {
            utility_screen.queue_free();
        }
    }

    (...)

Now, let's run it few times.

First reload, I just opened the editor…
None
<TestResource#-9223370135543142116>
Ok(Gd { id: -9223370135543142116, class: TestResource })
hello one frame later! I am <TestResource#-9223370135543142116>
goodbay cruel world

Initialize godot-rust (API v4.4.stable.official, runtime v4.4.stable.official)
First hot reload…
None
ERROR: godot-rust function call failed: MainScreenPluginWindow::set_test_resource()
    Reason: parameter #0 (core::option::Option<godot_core::obj::gd::Gd<on_editor_crash::main_screen_plugin::test_resource::TestResource>>) conversion
  Source: cannot convert to class TestResource: Gd { id: -9223370135543142116, class: Resource }
   at: godot_core::private::report_call_error (/home/irwin/apps/godot/opensource-contr/missing_docs/gdext/godot-core/src/private.rs:455)
<Resource#-9223370135543142116>
Err(Gd { id: -9223370135543142116, class: Resource })
hello one frame later! I am <TestResource#-9223370135543142116>
goodbay cruel world

Initialize godot-rust (API v4.4.stable.official, runtime v4.4.stable.official)
Second hot reload!
None
ERROR: cannot convert to class TestResource: Gd { id: -9223370135543142116, class: Resource }
<Resource#-9223370135543142116>
Err(Gd { id: -9223370135543142116, class: Resource })
hello one frame later! I am <TestResource#-9223370135543142116>
goodbay cruel world

Initialize godot-rust (API v4.4.stable.official, runtime v4.4.stable.official)
The very last hot reload – you should get an idea what is going on now.
None
ERROR: cannot convert to class TestResource: Gd { id: -9223370135543142116, class: Resource }
<Resource#-9223370135543142116>
Err(Gd { id: -9223370135543142116, class: Resource })
hello one frame later! I am <TestResource#-9223370135543142116>

Backtrace

   15   impl IEditorPlugin for MainScreenPlugin {
   16       fn enter_tree(&mut self) {
   17           ...
-> 18           let resource = ResourceLoader::singleton()
   19               .load("uid://bkhnrittppylb")
   20               .unwrap()
   21               .cast::<PackedScene>()
(lldb) n
ERROR: godot-rust function call failed: MainScreenPluginWindow::set_test_resource()
    Reason: parameter #0 (core::option::Option<godot_core::obj::gd::Gd<on_editor_crash::main_screen_plugin::test_resource::TestResource>>) conversion
  Source: cannot convert to class TestResource: Gd { id: -9223370135358592730, class: Resource }
   at: godot_core::private::report_call_error (/home/irwin/apps/godot/opensource-contr/missing_docs/gdext/godot-core/src/private.rs:455)
Process 607032 stopped

(lldb) thread backtrace
* thread #1, name = 'godot.linuxbsd.', stop reason = step over
  * frame #0: 0x00007fffb0495995 libon_editor_crash.so`_$LT$on_editor_crash..main_screen_plugin..main_screen_plugin..MainScreenPlugin$u20$as$u20$godot_core..gen..classes..editor_plugin..re_export..IEditorPlugin$GT$::enter_tree::he62f2a50c7c29d02(self=0x00005555854b3050) at main_screen_plugin.rs:23:22
    frame #1: 0x00007fffb047b02e libon_editor_crash.so`_$LT$on_editor_crash..main_screen_plugin..main_screen_plugin..MainScreenPlugin$u20$as$u20$godot_core..obj..traits..cap..ImplementsGodotVirtual$GT$::__virtual_call::virtual_fn::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::h7c1318dd50a2a88b((null)=0x00007fffffffbc0f, instance_ptr=0x0000555584e49940, (null)=<unavailable>) at main_screen_plugin.rs:14:1
    frame #2: 0x00007fffb048e648 libon_editor_crash.so`core::ops::function::FnOnce::call_once::h08db4d1bffc31a2d((null)={closure_env#0} @ 0x00007fffffffbc0f, (null)=(*mut godot_ffi::gen::gdextension_interface::__GdextClassInstance, ()) @ 0x00007fffffffbc10) at function.rs:250:5
    frame #3: 0x00007fffb0492b47 libon_editor_crash.so`_$LT$$LP$R$C$$RP$$u20$as$u20$godot_core..meta..signature..PtrcallSignatureTuple$GT$::in_ptrcall::h41c1556503363717(instance_ptr=0x0000555584e49940, call_ctx=0x00007fffffffbf28, args_ptr=0x0000000000000000, ret=0x0000000000000000, func=(libon_editor_crash.so`core::ops::function::FnOnce::call_once::h08db4d1bffc31a2d at function.rs:250), call_type=Virtual) at signature.rs:416:38
    frame #4: 0x00007fffb047afb7 libon_editor_crash.so`_$LT$on_editor_crash..main_screen_plugin..main_screen_plugin..MainScreenPlugin$u20$as$u20$godot_core..obj..traits..cap..ImplementsGodotVirtual$GT$::__virtual_call::virtual_fn::_$u7b$$u7b$closure$u7d$$u7d$::h92087326d15fc84c at main_screen_plugin.rs:14:1
    frame #5: 0x00007fffb046ccd0 libon_editor_crash.so`std::panicking::try::do_call::h210d547b40c76ff0(data="\U00000010\xbf\xff\xff\xff\U0000007f") at panicking.rs:587:40
    frame #6: 0x00007fffb048143b libon_editor_crash.so`__rust_try + 27
    frame #7: 0x00007fffb0480ed1 libon_editor_crash.so`std::panic::catch_unwind::h70090bfc5ee42ae9 at panicking.rs:550:19
    frame #8: 0x00007fffb0480e64 libon_editor_crash.so`std::panic::catch_unwind::h70090bfc5ee42ae9(f=<unavailable>) at panic.rs:358:14
    frame #9: 0x00007fffb0476a30 libon_editor_crash.so`godot_core::private::handle_panic::h1db08043b8a5e6fd(error_context={closure_env#0}<on_editor_crash::main_screen_plugin::main_screen_plugin::{impl#12}::__virtual_call::virtual_fn::{closure_env#0}, ()> @ 0x00007fffffffbdb0, code={closure_env#0} @ 0x00007fffffffbf50) at private.rs:391:9
    frame #10: 0x00007fffb047a13e libon_editor_crash.so`godot_core::private::handle_ptrcall_panic::hf4ee4686ef5bdec3(call_ctx=0x00007fffffffbf28, code=<unavailable>) at private.rs:437:38
    frame #11: 0x00007fffb04951f4 libon_editor_crash.so`_$LT$on_editor_crash..main_screen_plugin..main_screen_plugin..MainScreenPlugin$u20$as$u20$godot_core..obj..traits..cap..ImplementsGodotVirtual$GT$::__virtual_call::virtual_fn::h2087906f8e1a8984(instance_ptr=0x0000555584e49940, args_ptr=0x0000000000000000, ret=0x0000000000000000) at main_screen_plugin.rs:14:1
    frame #12: 0x000055555ba8609d godot.linuxbsd.editor.dev.x86_64`Node::_gdvirtual__enter_tree_call(this=0x0000555579f56800) at node.h:389:2
    frame #13: 0x000055555ba64696 godot.linuxbsd.editor.dev.x86_64`Node::_propagate_enter_tree(this=0x0000555579f56800) at node.cpp:310:2
    frame #14: 0x000055555ba76188 godot.linuxbsd.editor.dev.x86_64`Node::_set_tree(this=0x0000555579f56800, p_tree=0x00005555656062c0) at node.cpp:3287:24
    frame #15: 0x000055555ba6ac31 godot.linuxbsd.editor.dev.x86_64`Node::_add_child_nocheck(this=0x0000555565676040, p_child=0x0000555579f56800, p_name=0x0000555579f56a38, p_internal_mode=INTERNAL_MODE_DISABLED) at node.cpp:1636:21
    frame #16: 0x000055555ba6b351 godot.linuxbsd.editor.dev.x86_64`Node::add_child(this=0x0000555565676040, p_child=0x0000555579f56800, p_force_readable_name=false, p_internal=INTERNAL_MODE_DISABLED) at node.cpp:1668:20
    frame #17: 0x000055555a81163e godot.linuxbsd.editor.dev.x86_64`EditorNode::add_editor_plugin(p_editor=0x0000555579f56800, p_config_changed=false) at editor_node.cpp:3593:22
    frame #18: 0x000055555a811bb0 godot.linuxbsd.editor.dev.x86_64`EditorNode::add_extension_editor_plugin(p_class_name=0x00007fffffffc360) at editor_node.cpp:3626:19
    frame #19: 0x000055555e1f30a9 godot.linuxbsd.editor.dev.x86_64`GDExtensionEditorPlugins::add_extension_class(p_class_name=0x00007fffffffc360) at gdextension.cpp:1043:25
    frame #20: 0x000055555e204e7a godot.linuxbsd.editor.dev.x86_64`::gdextension_editor_add_plugin(p_classname=0x00005555851ea320) at gdextension_interface.cpp:1642:47
    frame #21: 0x00007fffb04e797c libon_editor_crash.so`godot_core::registry::class::register_class_raw::hb212b8fc720810bb(info=ClassRegistrationInfo @ 0x00007fffffffcb28) at class.rs:622:18
    frame #22: 0x00007fffb04e602a libon_editor_crash.so`godot_core::registry::class::auto_register_classes::h256c58dac86379a7(init_level=Editor) at class.rs:224:9
    frame #23: 0x00007fffb04b8c1d libon_editor_crash.so`godot_core::init::gdext_on_level_init::h1fd0869aa5d1e088(level=Editor) at mod.rs:178:5
    frame #24: 0x00007fffb04714ab libon_editor_crash.so`godot_core::init::ffi_initialize_layer::try_load::h7b62665509cf9eb8(level=Editor) at mod.rs:118:18
    frame #25: 0x00007fffb04713b1 libon_editor_crash.so`godot_core::init::ffi_initialize_layer::_$u7b$$u7b$closure$u7d$$u7d$::h4d829085ece74b09 at mod.rs:124:9
    frame #26: 0x00007fffb046cdef libon_editor_crash.so`std::panicking::try::do_call::h7c2957f1b216a0cf(data="\xa7\xcd\xff\xff\xff\U0000007f") at panicking.rs:587:40
    frame #27: 0x00007fffb048143b libon_editor_crash.so`__rust_try + 27
    frame #28: 0x00007fffb0480b90 libon_editor_crash.so`std::panic::catch_unwind::h4618bfdc82a893c5 at panicking.rs:550:19
    frame #29: 0x00007fffb0480b69 libon_editor_crash.so`std::panic::catch_unwind::h4618bfdc82a893c5(f={closure_env#1}<on_editor_crash::OnEditorCrashExtension> @ 0x00007fffffffccf8) at panic.rs:358:14
    frame #30: 0x00007fffb04771e9 libon_editor_crash.so`godot_core::private::handle_panic::hbf11752228563165(error_context={closure_env#0}<on_editor_crash::OnEditorCrashExtension> @ 0x00007fffffffcd58, code={closure_env#1}<on_editor_crash::OnEditorCrashExtension> @ 0x00007fffffffcd80) at private.rs:391:9
    frame #31: 0x00007fffb047136d libon_editor_crash.so`godot_core::init::ffi_initialize_layer::hb2a651b12fef95dc(_userdata=0x0000000000000000, init_level=3) at mod.rs:123:13
    frame #32: 0x000055555e1f06fa godot.linuxbsd.editor.dev.x86_64`GDExtension::initialize_library(this=0x000055556279ab60, p_level=INITIALIZATION_LEVEL_EDITOR) at gdextension.cpp:745:27
    frame #33: 0x000055555e20e87e godot.linuxbsd.editor.dev.x86_64`GDExtensionManager::_load_extension_internal(this=0x000055556279bce0, p_extension=0x00007fffffffcec8, p_first_load=false) at gdextension_manager.cpp:50:35
    frame #34: 0x000055555e20f020 godot.linuxbsd.editor.dev.x86_64`GDExtensionManager::reload_extension(this=0x000055556279bce0, p_path=0x00007fffffffcf50) at gdextension_manager.cpp:160:35
    frame #35: 0x000055555e20fcd6 godot.linuxbsd.editor.dev.x86_64`GDExtensionManager::reload_extensions(this=0x000055556279bce0) at gdextension_manager.cpp:311:20
    frame #36: 0x000055555a86d96a godot.linuxbsd.editor.dev.x86_64`void call_with_variant_args_helper<GDExtensionManager>(p_instance=0x000055556279bce0, p_method=e0 fb 20 5e 55 55 00 00 00 00 00 00 00 00 00 00, p_args=0x0000000000000000, r_error=0x00007fffffffd1a4, (null)=IndexSequence<> @ 0x00007fffffffcfd0)(), Variant const**, Callable::CallError&, IndexSequence<>) at binder_common.h:315:25
    frame #37: 0x000055555a86ce4d godot.linuxbsd.editor.dev.x86_64`void call_with_variant_args<GDExtensionManager>(p_instance=0x000055556279bce0, p_method=e0 fb 20 5e 55 55 00 00 00 00 00 00 00 00 00 00, p_args=0x0000000000000000, p_argcount=0, r_error=0x00007fffffffd1a4)(), Variant const**, int, Callable::CallError&) at binder_common.h:429:40
    frame #38: 0x000055555a86bb50 godot.linuxbsd.editor.dev.x86_64`CallableCustomMethodPointer<GDExtensionManager, void>::call(this=0x000055557c1d9fb0, p_arguments=0x0000000000000000, p_argcount=0, r_return_value=0x00007fffffffd1b0, r_call_error=0x00007fffffffd1a4) const at callable_method_pointer.h:105:26
    frame #39: 0x000055555de6580a godot.linuxbsd.editor.dev.x86_64`Callable::callp(this=0x0000555564961b78, p_arguments=0x0000000000000000, p_argcount=0, r_return_value=0x00007fffffffd1b0, r_call_error=0x00007fffffffd1a4) const at callable.cpp:57:15
    frame #40: 0x000055555e243d46 godot.linuxbsd.editor.dev.x86_64`CallQueue::_call_function(this=0x0000555562b5c4a0, p_callable=0x0000555564961b78, p_args=0x0000555564961b90, p_argcount=0, p_show_error=true) at message_queue.cpp:220:18
    frame #41: 0x000055555e244150 godot.linuxbsd.editor.dev.x86_64`CallQueue::flush(this=0x0000555562b5c4a0) at message_queue.cpp:268:20
    frame #42: 0x000055555babced7 godot.linuxbsd.editor.dev.x86_64`SceneTree::physics_process(this=0x00005555656062c0, p_time=0.016666666666666666) at scene_tree.cpp:534:38
    frame #43: 0x0000555558992686 godot.linuxbsd.editor.dev.x86_64`Main::iteration() at main.cpp:4485:60
    frame #44: 0x00005555588b48e4 godot.linuxbsd.editor.dev.x86_64`OS_LinuxBSD::run(this=0x00007fffffffd440) at os_linuxbsd.cpp:980:22
    frame #45: 0x00005555588ac539 godot.linuxbsd.editor.dev.x86_64`main(argc=4, argv=0x00007fffffffda78) at godot_linuxbsd.cpp:85:9
    frame #46: 0x00007ffff7c29d90 libc.so.6`__libc_start_call_main(main=(godot.linuxbsd.editor.dev.x86_64`main at godot_linuxbsd.cpp:56:34), argc=4, argv=0x00007fffffffda78) at libc_start_call_main.h:58:16
    frame #47: 0x00007ffff7c29e40 libc.so.6`__libc_start_main_impl(main=(godot.linuxbsd.editor.dev.x86_64`main at godot_linuxbsd.cpp:56:34), argc=4, argv=0x00007fffffffda78, init=0x00007ffff7ffd040, fini=<unavailable>, rtld_fini=<unavailable>, stack_end=0x00007fffffffda68) at libc-start.c:392:3
    frame #48: 0x00005555588ac2e5 godot.linuxbsd.editor.dev.x86_64`_start + 37

Long story short, the whole sequence during hot reload looks like this:
.1. Godot starts unloading extension.
.2. Godot caches all the properties on present instances & turns all the gdextension classes into native classes (Rust Class inheriting Resource -> Resource and so on)
.3. Godot starts initalizing the library – godot-rust starts registering all the clasess…
.7. Godot changes all the instances back to the Extension Classes and puts back all the cached properties where they belong.

.4. …and when we stumble upon EditorPlugin we initialize the plugin as well (it is being added to the editor etc). There is some wiggle room for failure here (failure being crash), if it tries to access properties with classes that haven't been registered yet. Let's assume that everything is good.
.5. Editor Plugin is being added to tree and runs enter_tree(). All good.
.6. Editor Plugin loads <Resource#-9223370135543142116>. Tool resources in editor are not pruned in-between reloads – they are kept alive… but it still haven't been changed back to the Extension Class 🙃 .

---

What can we do?

1. I already fixed the crash in case if we initialize EditorPlugin before other classes it relies on. (only on my side ofc, I'll open PR later)
2. IDK what to do about editor plugin behavior – I don't see any hook, signal or whatnot which would allow us to postpone initialization of the plugin until library is properly and fully reloaded. We can't await one frame while initializing the library, because it requires making way too much assertions (until we do it with the enter_tree virtual method – that's an option!)

[brezhnevtusks]

Thanks for the explanation Yarwin, that makes sense! I think for my use-cases I can get around this by delaying the initialization and maybe doing some casting shenanigans myself, but it's good to know what the cause is.

Should I keep this issue open?

[Yarwin]

Should I keep this issue open?

IMO yes, we need to figure out some good solution for the 2nd issue (plugin being initialized & added to the tree DURING hot reload, not after).

[TitanNano]

IMO yes, we need to figure out some good solution for the 2nd issue (plugin being initialized & added to the tree DURING hot reload, not after).

Maybe this is something that is better fixed in the engine itself?