Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crash on hot reload when binding gd pointers #984

Open
theKidOfArcrania opened this issue Dec 18, 2024 · 3 comments
Open

Crash on hot reload when binding gd pointers #984

theKidOfArcrania opened this issue Dec 18, 2024 · 3 comments

Comments

@theKidOfArcrania
Copy link
Contributor

theKidOfArcrania commented Dec 18, 2024

There is an issue in hot reloading where godot would segfault if you bind to self node when it gets hot reloaded.

Minimum example:

use godot::prelude::*;

#[repr(C)]
#[derive(GodotClass)]
#[class(init, base = Node, tool)]
pub struct MyNode {
    test: u64,
    base: Base<Node>,
}

#[godot_api]
impl INode for MyNode {
    fn ready(&mut self) {
        let call = Callable::from_local_fn(
            "test",
            |_| {
                Ok(Variant::nil())
            },
        ).bindv(&Array::from_iter([self.to_gd().to_variant()]));
        self.base_mut().connect(c"tree_entered", &call);
    }
}

struct Test;

#[gdextension]
unsafe impl ExtensionLibrary for Test {}

When a scene with this node is loaded in godot, and then you rebuild (and thus trigger a hot reload), and then attempt to close that scene, it will then cause godot to crash entirely.

@Bromeon
Copy link
Member

Bromeon commented Dec 18, 2024

Thanks for reporting. Is it crash or panic? Where exactly, do you have a stacktrace?

@theKidOfArcrania
Copy link
Contributor Author

theKidOfArcrania commented Dec 18, 2024

It's a segmentation fault. I don't have a stack trace for this simple version since this one actually just directly segfaults without even dumping any errors

Although I think it is crashing somewhere in godot_core::builtin::callable::custom_callable::rust_callable_to_string_named because that was a stacktrace I found when running my actual code

@theKidOfArcrania
Copy link
Contributor Author

When I get some time later, I can pull it up into gdb and dump the stacktrace that way

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants