Project Crashing in Godot 4.3

[TravsVoid]

I installed from the asset library and placed the .dll files for 4.3 and windows but it's causing Godot to crash when I create a Tree3D scene. This actually broke my main project after I instantiated a tree scene into my main level and it crashed every time I opened my project. I had to then edit the scene file to remove the tree references to get back into it.

Testing.mp4

Also I see debug, release, 32bit, and 64bit versions of the dll's. Do I need both the debug and release dll along with both 32 and 64 bit?

Godot Project:

treeissue.zip

[FibreFoX]

Don't clone the repository, create a fresh project and add the binaries from the GitHub Actions:
https://github.com/JekSun97/gdTree3D/actions/runs/10851955753

Can you check with that files?

[TravsVoid]

I can confirm the same issue is occurring for me using that download in a fresh project.

[FibreFoX]

@TravsVoid Can you post a fresh project with these files? The first one contained too much distracting stuff. Just an empty project with the changes required for the crash (including the addon).

Sounds very interesting, like a general bug. Will try to check on other OS systems too when having that project (to rule out it being an OS dependent issue).

[FibreFoX]

Another question: have you checked if the issue is present in older versions of Godot?

[JekSun97]

Try running the project from the console to see the errors that have occurred. I migrated my project from 4.2 to 4.3 using Windows as well, but I don't have such problems

[TravsVoid]

Here is the new 4.3 test, but I did try out the 4.2 version and the same crash is happening for me.

Tree.Test.mp4

treetest.zip

[vabrador]

I'm experiencing this crash as well in 4.3:
Engine version: Godot Engine v4.3.stable.official (77dcf97d82cbfe4e4615475fa52ca03da645dbd8) (note: my stack trace is from a custom build so I have some debug symbols)
Renderer: Forward+
Addon binary: binaries-windows-godot4.3-x86_64

The reproduction steps are as in TravsVoid's video above; specifically, the crash only occurs when changing editor tabs to a scene with a Tree3D in it. For me, I can have the editor successfully start up into a scene containing a Tree3D, and it crashes if I tab away to a different scene and back.

Here's the most detailed backtrace I could get, from using my own built version of 4.3 x64 godot_cpp, and my own built editor of 4.3, which is a mostly-unchanged Godot 4.3 build (the crash occurs whether I use my own build or 4.3-stable):

CrashHandlerException: Program crashed
Engine version: Godot Engine v4.3.1.rc.custom_build (94ac6d4c38cee511f193459dd2070fbc4371bcb3)
Dumping the backtrace. Please include this when reporting the bug to the project developer.
[0] <couldn't map PC to fn name>
[1] <couldn't map PC to fn name>
[2] <couldn't map PC to fn name>
[3] <couldn't map PC to fn name>
[4] <couldn't map PC to fn name>
[5] GDExtensionMethodBind::call (C:\Users\vabs\dev\godot_dev\godot\core\extension\gdextension.cpp:251)
[6] ClassDB::get_property (C:\Users\vabs\dev\godot_dev\godot\core\object\class_db.cpp:1560)
[7] Object::get (C:\Users\vabs\dev\godot_dev\godot\core\object\object.cpp:328)
[8] EditorFolding::_fill_folds (C:\Users\vabs\dev\godot_dev\godot\editor\editor_folding.cpp:116)
[9] EditorFolding::_fill_folds (C:\Users\vabs\dev\godot_dev\godot\editor\editor_folding.cpp:128)
[10] EditorFolding::save_scene_folding (C:\Users\vabs\dev\godot_dev\godot\editor\editor_folding.cpp:148)
[11] EditorNode::_set_current_scene_nocheck (C:\Users\vabs\dev\godot_dev\godot\editor\editor_node.cpp:3874)
[12] EditorNode::_set_current_scene (C:\Users\vabs\dev\godot_dev\godot\editor\editor_node.cpp:3869)
[13] CallableCustomMethodPointer<EditorNode,int>::call (C:\Users\vabs\dev\godot_dev\godot\core\object\callable_method_pointer.h:103)
[14] Callable::callp (C:\Users\vabs\dev\godot_dev\godot\core\variant\callable.cpp:58)
[15] Object::emit_signalp (C:\Users\vabs\dev\godot_dev\godot\core\object\object.cpp:1190)
[16] Node::emit_signalp (C:\Users\vabs\dev\godot_dev\godot\scene\main\node.cpp:3902)
[17] Object::emit_signal<int> (C:\Users\vabs\dev\godot_dev\godot\core\object\object.h:936)
[18] EditorSceneTabs::_scene_tab_changed (C:\Users\vabs\dev\godot_dev\godot\editor\gui\editor_scene_tabs.cpp:75)
[19] CallableCustomMethodPointer<EditorSceneTabs,int>::call (C:\Users\vabs\dev\godot_dev\godot\core\object\callable_method_pointer.h:103)
[20] Callable::callp (C:\Users\vabs\dev\godot_dev\godot\core\variant\callable.cpp:58)
[21] Object::emit_signalp (C:\Users\vabs\dev\godot_dev\godot\core\object\object.cpp:1190)
[22] Node::emit_signalp (C:\Users\vabs\dev\godot_dev\godot\scene\main\node.cpp:3902)
[23] Object::emit_signal<int> (C:\Users\vabs\dev\godot_dev\godot\core\object\object.h:936)
[24] TabBar::gui_input (C:\Users\vabs\dev\godot_dev\godot\scene\gui\tab_bar.cpp:287)
[25] Control::_call_gui_input (C:\Users\vabs\dev\godot_dev\godot\scene\gui\control.cpp:1831)
[26] Viewport::_gui_call_input (C:\Users\vabs\dev\godot_dev\godot\scene\main\viewport.cpp:1570)
[27] Viewport::_gui_input_event (C:\Users\vabs\dev\godot_dev\godot\scene\main\viewport.cpp:1799)
[28] Viewport::push_input (C:\Users\vabs\dev\godot_dev\godot\scene\main\viewport.cpp:3259)
[29] Window::_window_input (C:\Users\vabs\dev\godot_dev\godot\scene\main\window.cpp:1680)
[30] CallableCustomMethodPointer<Window,Ref<InputEvent> const &>::call (C:\Users\vabs\dev\godot_dev\godot\core\object\callable_method_pointer.h:103)
[31] Callable::callp (C:\Users\vabs\dev\godot_dev\godot\core\variant\callable.cpp:58)
[32] Callable::call<Ref<InputEvent> > (C:\Users\vabs\dev\godot_dev\godot\core\variant\variant.h:876)
[33] DisplayServerWindows::_dispatch_input_event (C:\Users\vabs\dev\godot_dev\godot\platform\windows\display_server_windows.cpp:3557)
[34] Input::_parse_input_event_impl (C:\Users\vabs\dev\godot_dev\godot\core\input\input.cpp:775)
[35] Input::flush_buffered_events (C:\Users\vabs\dev\godot_dev\godot\core\input\input.cpp:1056)
[36] DisplayServerWindows::process_events (C:\Users\vabs\dev\godot_dev\godot\platform\windows\display_server_windows.cpp:3025)
[37] OS_Windows::run (C:\Users\vabs\dev\godot_dev\godot\platform\windows\os_windows.cpp:1666)
[38] widechar_main (C:\Users\vabs\dev\godot_dev\godot\platform\windows\godot_windows.cpp:181)
[39] _main (C:\Users\vabs\dev\godot_dev\godot\platform\windows\godot_windows.cpp:208)
[40] main (C:\Users\vabs\dev\godot_dev\godot\platform\windows\godot_windows.cpp:220)
[41] __scrt_common_main_seh (D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288)
[42] <couldn't map PC to fn name>

Admittedly I haven't figured out how to get debug symbols in a GDExtension; I looked around but couldn't find a straight-forward guide for this and I'm pretty green to using GDExtension. If anybody has a tip here I can try to get better debug information.

[FibreFoX]

To sum up the video:

• opening a fresh project with a single Tree3D instance (all default settings)
• opening a new 3d scene
• closing that new (unsaved) 3d scene
• crash happens

thanks @TravsVoid for the video and the clean project, that helps

thanks @vabrador too, not sure about the debug-information inside the GDExtensions, they "should" be included in the binaries, but maybe they are (still) compiled somehow wrong (documentation from Godot is a bit wonky there)

I will experiment with creating the binaries with a Windows VM again, maybe that will give some dbg files again to find the problem

[FibreFoX]

@Yora0 this is a different issue you are having, please iopen a different bug issue

[JekSun97]

There is a suspicion that the crash problem is somehow related to this problem #1, probably the links to the meshes are lost somewhere...

[dootus]

I can confirm this happening in the linux build as well. Crashes on changing editor tab to a scene that contains a Tree3D.

One possible workaround is to always close any scene that contains a tree and open it from the FileSystem browser instead of changing tabs. It can open the scene without crashing, but it's inconvenient.

[MendezDev42]

Not sure if helpful, but i am currently experiencing the very same, switching tabs to the one containing Tree3D instantly crashes the editor, enve just blank scene, blank project, with just one tree, (create tree scene, create new scene, return to tree - crash)

edit: using the demo project, behavior is exactly the same

edit2: forward+ and mobile renderers both does the same

edit3: workaround - issue fixed itself the moment i saved the tree as its own scene, and added only that to the other scenes, crashes are gone for now

[Rontorx]

@MendezDev42 I had same issue, older version of plugin doesn't have this problem https://github.com/JekSun97/gdTree3D/releases/tag/Tree3D_v0.6, seems to me like fixing #1 could've caused this, but i am not sure

[MendezDev42]

@MendezDev42 I had same issue, older version of plugin doesn't have this problem https://github.com/JekSun97/gdTree3D/releases/tag/Tree3D_v0.6, seems to me like fixing #1 could've caused this, but i am not sure

so after cleaning my project i realized it was not creating and saving the node that fixed it for me - its even more weird :

i had to add Subfolder within the addons/Tree3D/ folder, named whatever, i went for "ALL" and i put there the release and debug dlls (i did this to store them not realizing godot will load them)

this results in error on each runtime (that does not crash the app) saying node Tree3D was already registered, BUT it prevents editor from crashing! - and even built project runs well, not sure if this helps, but I think you are right that its related to fixing issue #1

[solitaryurt]

Also getting crashes on 4.4-beta3

I can confirm this happening in the linux build as well. Crashes on changing editor tab to a scene that contains a Tree3D.

I also got crashes moving the Tree3D node in the scene tree.

[solitaryurt]

When opening a scene with a Tree3D node the function _enter_tree was causing crashes:

void Tree3D::_enter_tree() {
	// HACK!! To fix duplication issue before Godot 4.3.
	TypedArray<Node> children = get_children(true);
	for (int i =0; i < children.size(); ++i) {
		Node *node = cast_to<MeshInstance3D>(children[i]);
		if (node->has_meta(get_hack_meta_identifier()) && cast_to<Node>(node->get_meta(get_hack_meta_identifier())) != this) {
			remove_child(node);
			node->queue_free();
		}
	}
}

And when reparenting a Tree3D to another node within a scenetree the function _exit_tree was causing crashes:

void Tree3D::_exit_tree() {
	//godot::UtilityFunctions::print("Tree3D exit");
	remove_child(trunk_inst);
	trunk_inst=nullptr;
	if(twig_inst)
	{
	remove_child(twig_inst);
	twig_inst=nullptr;
	}
	
}

Determined that by commenting out the body of those functions and performing my tests. Guessing its a memory issue.

[aphity]

I faced probably the same problem in Godot 4.4. In my case, the crash was in Tree3D::get_material_trunk, due to trunk_inst being null.

I added some logging and that's what I've seen while loading my project:

Tree3D::Tree3D
Tree3D::_enter_tree
Tree3D::_exit_tree
Tree3D::_enter_tree

I'm not really sure why does Godot first adds the tree to the scene, then removes it and then adds it again. But since Tree3D::_exit_tree sets trunk_inst to null, and it's never set back to anything useful, a crash is imminent as soon as get_material_trunk (or likely any method accessing trunk_inst) is called.

Now, I didn't yet study Tree3D code deep enough, but this is what seems to have helped in my case:

1. Don't nullify pointers in _exit_tree:

void Tree3D::_exit_tree() {
	//godot::UtilityFunctions::print("Tree3D exit");
	remove_child(trunk_inst);
	//trunk_inst=nullptr;
	if(twig_inst)
	{
	remove_child(twig_inst);
	//twig_inst=nullptr;
	}
}

2. Move add_child calls from the constructor to _enter_tree:

Tree3D::Tree3D() {
	trunk_inst = memnew(MeshInstance3D);
	twig_inst = memnew(MeshInstance3D);	
/*	this->add_child(trunk_inst);
	this->add_child(twig_inst);
	UpdateAllMeshes();*/

	// HACK!! To fix duplication issue before Godot 4.3.
	trunk_inst->set_meta(get_hack_meta_identifier(), this);
	twig_inst->set_meta(get_hack_meta_identifier(), this);
}

void Tree3D::_enter_tree() {
    // .... 
    add_child(trunk_inst);

    if (twig_inst)
        add_child(twig_inst);

    UpdateAllMeshes();
}

(I also moved UpdateAllMeshed too, don't know whether it's necessary).

This allowed me to load the project, but I'm not sure if it's a good solution. @FibreFoX what do you think about this?

[JekSun97]

This PR should fix all the glitches, but it will only be in 4.5.