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

Condition ' p_elem->_root != this ' is true error for unknown reason #22565

Closed
crabctrl opened this issue Sep 30, 2018 · 3 comments
Closed

Condition ' p_elem->_root != this ' is true error for unknown reason #22565

crabctrl opened this issue Sep 30, 2018 · 3 comments

Comments

@crabctrl
Copy link

crabctrl commented Sep 30, 2018

Godot version:
v3.0.6 Stable (installed from AUR package; compiled)

OS/device including version:
Arch Linux, laptop /w i7, Intel Graphics (graphics not relevant)

Issue description:
The error Condition ' p_elem->_root != this ' is true begins getting spammed to console anywhere between 0-30 seconds after game start

Steps to reproduce:
Unknown (I'm sorry)

Minimal reproduction project:
Since I've been unable to reproduce the issue I don't have any kind of reproduction project ofc. Here's the tarball for my entire project if it's wanted.
OpenFortress.tar.gz

Since I haven't given much to work with, I'll go over some of the things I've already checked. The only time I'm running add_child, remove_child, or queue_free (either directly or via call_deferred) is at game start (specifically on connection to the server). Sometimes the error begins immediately, and sometimes it takes some amount of time. Usually the game continues functioning fine even after the error has begun printing. Once the error has started printing, it continues to spam out into console until the process is killed. Setting the client to not load the map has no effect.

Moving specifically onto my project's code (I understand you probably don't have time to look through my code but in case you do), as you can see by the debug line in Client.gd:38, I am never removing nodes, and Client.gd:50 is only called once (on connection to the server). Decreasing the server tick rate delays the error slightly, but other than that has no effect (Server.gd:5). If you're trying to run my code, the movement keys are ,aoe not wasd, and although the code should work on other platforms, the dedicated_server.sh script as well as the Host button in-game will not work OOTB on Windows or Mac, so you might need to take a look at the dedicated_server.sh script and adapt it to your own needs.

Again, I know I haven't really given much to work with, but any help is greatly appreciated.

@crabctrl
Copy link
Author

crabctrl commented Oct 1, 2018

Some others have reproduced this using my code on their (Windows, prebuilt stable) machines, although it took a bit of persuasion. This confirms it's not just a problem with my own machine, or with my custom build (by "custom" I just mean it was compiled from source, there's no actual changes to the source)

@crabctrl
Copy link
Author

crabctrl commented Oct 4, 2018

So since nobody seems interested in helping me with this issue, I've taken some initiative of my own. Here's GDB backtrace at the point of the error.

#0  _err_print_error (p_function=0x5555591dde31 <SelfList<Node>::List::add(SelfList<Node>*)::__FUNCTION__> "add", p_file=0x5555591ddccd "core/self_list.h", p_line=46, p_error=0x5555591ddca8 "Condition ' p_elem->_root ' is true.", p_type=ERR_HANDLER_ERROR)
    at core/error_macros.cpp:84
#1  0x00005555574a12d6 in SelfList<Node>::List::add (this=0x55555a2c3c18, p_elem=0x7fffcc015270) at core/self_list.h:46
#2  0x0000555557497dae in Spatial::_propagate_transform_changed (this=0x7fffcc015080, p_origin=0x7fffcc010540) at scene/3d/spatial.cpp:118
#3  0x0000555557497cb1 in Spatial::_propagate_transform_changed (this=0x7fffcc010540, p_origin=0x7fffcc010540) at scene/3d/spatial.cpp:111
#4  0x0000555557499586 in Spatial::set_translation (this=0x7fffcc010540, p_translation=...) at scene/3d/spatial.cpp:312
#5  0x000055555630fba8 in MethodBind1<Vector3 const&>::call (this=0x555559f1ecf0, p_object=0x7fffcc010540, p_args=0x7ffff03e0440, p_arg_count=1, r_error=...) at core/method_bind.gen.inc:729
#6  0x0000555558491085 in ClassDB::set_property (p_object=0x7fffcc010540, p_property=..., p_value=..., r_valid=0x7ffff03e0780) at core/class_db.cpp:1030
#7  0x0000555556106565 in GDScriptFunction::call (this=0x7fffcc00ccf0, p_instance=0x7fffcc00f2f0, p_args=0x7ffff03e2bb0, p_argcount=1, r_err=..., p_state=0x0) at modules/gdscript/gdscript_function.cpp:630
#8  0x0000555556175dbe in GDScriptInstance::call (this=0x7fffcc00f2f0, p_method=..., p_args=0x7ffff03e2bb0, p_argcount=1, r_error=...) at modules/gdscript/gdscript.cpp:1151
#9  0x0000555558525497 in Object::call (this=0x7fffcc010540, p_method=..., p_args=0x7ffff03e2bb0, p_argcount=1, r_error=...) at core/object.cpp:893
#10 0x0000555558439695 in Variant::call_ptr (this=0x7ffff03e2b38, p_method=..., p_args=0x7ffff03e2bb0, p_argcount=1, r_ret=0x0, r_error=...) at core/variant_call.cpp:1016
#11 0x000055555610ef10 in GDScriptFunction::call (this=0x55555a469c00, p_instance=0x55555a474570, p_args=0x7ffff03e5378, p_argcount=2, r_err=..., p_state=0x0) at modules/gdscript/gdscript_function.cpp:808
#12 0x0000555556175dbe in GDScriptInstance::call (this=0x55555a474570, p_method=..., p_args=0x7ffff03e5378, p_argcount=2, r_error=...) at modules/gdscript/gdscript.cpp:1151
#13 0x0000555558525497 in Object::call (this=0x55555a47ea50, p_method=..., p_args=0x7ffff03e5378, p_argcount=2, r_error=...) at core/object.cpp:893
#14 0x0000555558439695 in Variant::call_ptr (this=0x55555a483de0, p_method=..., p_args=0x7ffff03e5378, p_argcount=2, r_ret=0x0, r_error=...) at core/variant_call.cpp:1016
#15 0x000055555610ef10 in GDScriptFunction::call (this=0x55555a489ef0, p_instance=0x55555a45bab0, p_args=0x7ffff03e7938, p_argcount=1, r_err=..., p_state=0x0) at modules/gdscript/gdscript_function.cpp:808
#16 0x0000555556175dbe in GDScriptInstance::call (this=0x55555a45bab0, p_method=..., p_args=0x7ffff03e7938, p_argcount=1, r_error=...) at modules/gdscript/gdscript.cpp:1151
#17 0x0000555558525497 in Object::call (this=0x55555a47be00, p_method=..., p_args=0x7ffff03e7938, p_argcount=1, r_error=...) at core/object.cpp:893
#18 0x0000555558439695 in Variant::call_ptr (this=0x7ffff03e9b40, p_method=..., p_args=0x7ffff03e7938, p_argcount=1, r_ret=0x0, r_error=...) at core/variant_call.cpp:1016
#19 0x000055555610ef10 in GDScriptFunction::call (this=0x55555a474630, p_instance=0x55555a45bab0, p_args=0x7ffff03e9dc8, p_argcount=1, r_err=..., p_state=0x0) at modules/gdscript/gdscript_function.cpp:808
#20 0x0000555556175dbe in GDScriptInstance::call (this=0x55555a45bab0, p_method=..., p_args=0x7ffff03e9dc8, p_argcount=1, r_error=...) at modules/gdscript/gdscript.cpp:1151
#21 0x0000555558525497 in Object::call (this=0x55555a47be00, p_method=..., p_args=0x7ffff03e9dc8, p_argcount=1, r_error=...) at core/object.cpp:893
#22 0x00005555586d2764 in _Thread::_start_func (ud=0x55555a459ab0) at core/bind/core_bind.cpp:2289
#23 0x000055555678a458 in ThreadPosix::thread_callback (userdata=0x55555a4b0550) at drivers/unix/thread_posix.cpp:70
#24 0x00007ffff67d1a9d in start_thread () from /usr/lib/libpthread.so.0
#25 0x00007ffff63cca43 in clone () from /usr/lib/libc.so.6

@akien-mga akien-mga added this to the 3.1 milestone Oct 5, 2018
@crabctrl
Copy link
Author

crabctrl commented Oct 5, 2018

So I've found the issue; the problem is that I'm setting the translation of a node from a thread. It would be nice if the docs were clearer about thread safety.

Additionally it would be nice if the engine trusted me to use mutexes properly, although I understand that's difficult considering plenty of internal code could modify things like the translation as well. I'll close this issue in a bit unless anybody else wants to discuss, since my specific problem has been fixed

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

No branches or pull requests

2 participants