No helpful message on C++ stack overflow

[lemonlambda]

// This causes a crash no matter if the node even exists in a scene that's how good it is.

use godot::classes::*;
use godot::prelude::*;

#[derive(GodotClass)]
#[class(base = Node)]
pub struct Crasher {
    child: Gd<CrasherChild>,

    base: Base<Node>,
}

#[godot_api]
impl INode for Crasher {
    fn init(base: Base<Node>) -> Self {
        Self {
            child: CrasherChild::new_alloc(),

            base,
        }
    }
}

#[derive(GodotClass)]
#[class(base = Node)]
pub struct CrasherChild {
    parent: Gd<Crasher>,

    base: Base<Node>,
}

#[godot_api]
impl INode for CrasherChild {
    fn init(base: Base<Node>) -> Self {
        Self {
            parent: Crasher::new_alloc(),

            base,
        }
    }
}

This causes godot 4.3 to crash even if the node(s) don't exist in the scene. A warning or an error for this would be nice if possible.

[Yarwin]

This example causes never-ending loop which actually causes the crash (Crasher creates CrasherChild and vice versa); It should happen in the editor as well.

This issue will be rendered null after #1051 will be merged (i.e in 0.3.0 release) – it will remove Export implementations for Gd<T> and DynGd<T, D>. For now on one can use Option<Gd<T>> and OnReady<Gd>` (no breaking changes in user facing API are planned for now).

See also: #892

[lilizoey]

i dont see why removing the Export impl for Gd would do anything here, the child/parent fields aren't exported.

[Yarwin]

Oh, my bad, the discord example included the #[export].

Same use case appeared in the now hidden repo.

The question is if anything can be done about that – should we permit using Gd<T> as a property at all? (IMO not, if user wants to create never-ending loop and crash the engine then we should allow that 🤔)

[lilizoey]

i dont think we can prevent it though. rust doesn't have any non-intrusive way to stop a type from being used as a field in a struct.

[lemonlambda]

i dont think we can prevent it though. rust doesn't have any non-intrusive way to stop a type from being used as a field in a struct.

You can use a proc-macro to detect if it's self-referential but this requires both structs to have this proc-macro. This could be done with GodotClass. This is probably over-cumbersome though.

[lilizoey]

i dont think we can prevent it though. rust doesn't have any non-intrusive way to stop a type from being used as a field in a struct.

You can use a proc-macro to detect if it's self-referential but this requires both structs to have this proc-macro. This could be done with GodotClass. This is probably over-cumbersome though.

yeah but it also doesn't work with indirection.

the above code is also fine as long as it's not cyclic, and there are cases where you might want that. which also increases the complexity of detecting this, either needing an opt-out or cycle detection, and it's not easy to reliably share state between macros invocations.

we might be able to detect a cycle and error out early, or at least give a better error message. but we can't in general detect all infinite loops.

[Bromeon]

@lemonlambda You're writing the godot-rust equivalent of this code*:
_{* which I find quite elegant}

#[derive(Default)]
struct Parent {
    child: Box<Child>,
}

#[derive(Default)]
struct Child {
    parent: Box<Parent>,
}

fn main() {
    let _crash = Parent::default();
}

I don't really see why/how we should try to prevent this?

[lemonlambda]

@lemonlambda You're writing the godot-rust equivalent of this code*: * which I find quite elegant

#[derive(Default)]
struct Parent {
child: Box,
}

#[derive(Default)]
struct Child {
parent: Box,
}

fn main() {
let _crash = Parent::default();
}

I don't really see why/how we should try to prevent this?

At least with-in rust you will get a stack overflow error, with godot you will just get a crash with no meaningful error. I guess that's my main problem.

[Bromeon]

That's a Godot problem though, no? The equivalent GDScript probably has the same behavior?

Or what should the Rust bindings concretely do to detect and act on such cases?

[lemonlambda]

I have no clue. Maybe it is a godot issue instead and should report it as so.