Godot 4.3 GDExtension is more strict about wrapping Godot Objects than 4.2

bignobody · September 22, 2024, 2:28pm

Godot Version

4.3

Question

I am working on a custom GDExtension and recently tried upgrading my code base from 4.2 to 4.3. It seems 4.3 is much more strict about forcing me to wrap Godot Objects than 4.2 was, as it force crashes the application if you don’t:

ERROR: BUG: Godot Object created without binding callbacks. Did you forget to use memnew()?
at: (godot-cpp\src\classes\wrapped.cpp:87)

The thing is, I didn’t forget - it was on purpose. There are plenty of times where it feels more practical to have Godot Objects as class members instead of dynamically creating everything. For example, I have a lot of UI classes that inherit PanelContainer and have many UI controls as class members:

protected:

static void _bind_methods();

godot::GridContainer GridFlow;
godot::FlowContainer CenterDetailsFlow;
godot::Label	CenterSizeLabel;
godot::OptionButton CenterSizes;
godot::Label	CenterVertexRatioLabel;
godot::OptionButton CenterVertexRatios;
    ...

It seems like Godot 4.3 is going to force me to change these all to pointers and memnew/memdelete them.

Is there any option to allow me to use Godot Objects that I don’t care about binding callbacks in the way 4.2 allowed me to?

pennyloafers · September 22, 2024, 2:40pm

That is not the case, all Godot::objects that are created with new need to use memnew in order to glue with the Godot’s::object class (Node inherits Object class). If Godot engine needs to interact with it it needs the memnew glue.

See memory.h, and the object.cpp for post initialization of memnew.

memory.h

github.com

godotengine/godot/blob/e4e024ab88efe74677769395886bc1b09eccbac7/core/os/memory.h#L125


      
          #define memfree(m_mem) Memory::free_static(m_mem)
          
          _ALWAYS_INLINE_ void postinitialize_handler(void *) {}
          
          template <typename T>
          _ALWAYS_INLINE_ T *_post_initialize(T *p_obj) {
          	postinitialize_handler(p_obj);
          	return p_obj;
          }
          
          #define memnew(m_class) _post_initialize(new ("") m_class)
          
          #define memnew_allocator(m_class, m_allocator) _post_initialize(new (m_allocator::alloc) m_class)
          #define memnew_placement(m_placement, m_class) _post_initialize(new (m_placement) m_class)
          
          _ALWAYS_INLINE_ bool predelete_handler(void *) {
          	return true;
          }
          
          template <typename T>
          void memdelete(T *p_class) {

Object.cpp

github.com

godotengine/godot/blob/e4e024ab88efe74677769395886bc1b09eccbac7/core/object/object.cpp#L2184


      
          			}
          		}
          		memfree(_instance_bindings);
          	}
          }
          
          bool predelete_handler(Object *p_object) {
          	return p_object->_predelete();
          }
          
          void postinitialize_handler(Object *p_object) {
          	p_object->_initialize();
          	p_object->_postinitialize();
          }
          
          void ObjectDB::debug_objects(DebugFunc p_func) {
          	spin_lock.lock();
          
          	for (uint32_t i = 0, count = slot_count; i < slot_max && count != 0; i++) {
          		if (object_slots[i].validator) {
          			p_func(object_slots[i].object);

bignobody · September 22, 2024, 3:57pm

Thanks, this is clear to me and I do this anywhere where I need to use Signals, etc. But in my example, these Godot Objects are not created with new or memnew, they are implicitly constructed as part of the class. This seemed to be working fine for my needs in Godot 4.2, but 4.3 is explicitly crashing because of it.

bignobody · September 22, 2024, 4:08pm

I do accept that the answer may be “just because Godot 4.2 let you do this, doesn’t mean you should have been doing this”, I just wanted to be sure before I set out on a significant code refactor…

pennyloafers · September 22, 2024, 5:03pm

I would have to investigate the history more, but the functionality did change subtly, but overall looks the same. ( I think this has been a requirement since the beginning of Godot. And if not followed could lead to leaked memory)

I wonder if there was some implicit call to postinitialize the class (which eventually calls bind_methods) when allocating memory.

Even so the impact is small, just change new calls to memnew and that’s it.

Node = new Node(args)
// Changes to 
Node = memnew( Node(args) )

And a similar thing is required for memdelete

If you want objects on the stack you could try calling postinitialize_handler manually. ( And predelete_handler respectfully )

bignobody · September 22, 2024, 5:48pm

Thanks very much for your insights! I am going to proceed with my code refactor with the philosophy of “if it’s a Godot Object, it must be explicitly created and destroyed with memnew and memdelete, regardless of whether I think the engine needs to know about it or not”. Time to make coffee and put on some good music.

I just wanted to try the new FogMode additions and definitely got more than I bargained for here