Godot: "Condition 'p_elem->_root!=this' is true." errors when adding nodes from a thread

[supercom32]

Hi everyone,

I seem to be randomly getting these "Condition 'p_elem->_root!=this' is true." errors. When they happen, it causes my "Errors" tab to fill up with messages. I had a look in core/self_list.h:59 to see what is up, but I'm afraid it's all too technical for me. (^_^);

Has anyone else experienced this before, and/or know why it would be generated? Or that matter, what the error actually means? What's strange is that it happens randomly, so I have no real way of investigating further.

[akien-mga]

Does it still happen in the current master branch, and if so, can you provide a minimal project that reproduces the issue and/or describe the steps to reproduce?

[reduz]

I think I havent seen this error in a while did anyone?

[akien-mga]

I think it has been fixed already.

[mysticfall]

I'm having the same issue with a pretty recent build (68f277477b5a5f3003405e36c6b6853720cb91de) of the master branch:

ERROR: remove: Condition ' p_elem->_root != this ' is true.
   At: core/self_list.h:77.

Should we reopen this issue?

[akien-mga]

Now that it's reopened let's use this issue, but next time please open a new one instead. This issue has been fixed more than half a year ago, and AFAIK it's not present in the 3.0 stable version. So the issue you're having now, though showing the same symptoms, is likely a recently introduced bug and thus not present since May 2017 as reported here.

[mysticfall]

Sorry if I revived an irrelevant issue. I thought it was the same one, since the message was identical and there was no mention of the actual commit that fixed the problem in this thread.

I'll report a separate issue in future, if I encounter a similar case as this.

[akien-mga]

No problem :) But yeah, those messages are quite generic and can be triggered by many things (typically a GUI element in the editor that starts making changes too early while its elements haven't been initialized yet), so we might have different causes leading to the same error message.

[mysticfall]

It seems that I can reproduce this issue quite often. Is there anything I can do to help track down the cause, like putting some debug statement inside the editor code?

If so, please let me know and I'll test it as soon as I can.

[vnen]

@mysticfall that can be tracked only if you put Godot into an external debugger and add a breakpoint in the referred line. Then you can check the call stack to have a hint of where it starts giving problems.

[mysticfall]

@vnen Thanks for the information. I wish I knew enough of C++ to debug this :disappointed:

[organicpencil]

Most recently I got this in the 2.1 branch when calling astar.get_point_path after mistakenly making duplicate connections with bidirectional=true. It still spit out the path just fine. That was weird to debug.

Probably obscure issue with user code. I will pray for you.

[MortimerMcMire]

setting bidirectional to false fixed that error for me

the error is triggered whenever a new object has to calculate a path between two astar nodes that were connected to each other twice (easy to do if you run code on each node to connect it to every other adjacent node, bidirectional = true)

it's probably triggered from other things too, but I think in this case it's worth breaking out the error into a more descriptive "You're connecting your astar points twice, try setting bidirectional to false"

[mysticfall]

In my case, I don't use any path finding features but still got the error. But if most others who have the same symptom only experience it in that context, then I agree we should change the title to something more descriptive.

I'll try to find a way to reproduce it more reliably and open another issue in that case.

[ianscottcamp]

@akien-mga I had this error back in v 2.1 and the problem only worsened for me in 3.0. For me the issue occurs when adding nodes to the current running scene tree from a thread

[supercom32]

@ianscottcamp: I also had the same issue. That is, when adding multiple nodes to the current running scene from a thread, sometimes I got these errors. Seems thread related to be honest.

[ianscottcamp]

@supercom32 yeah i narrowed it down to add_child from a thread which using call deferred got rid of the p_elem error and revealed other errors that weren't being thrown before. Fixing those new errors helped reduce random crashes i was getting. Using call deferred did give me lag though as i am adding around 1000 nodes at a time. I reverted back to not using it as i could live with p elem error over the bad lag on world generation. My game is procedural gen exploration

[ianscottcamp]

@mortimermcmire Yeah a bunch of people mentioned astar was not thread safe. I started using
astar but could not easily control connections in my game since mine is an
infinite expanding proc generated terrain. I ended up making my own
pathfinding algo to suit my needs. Are you using astar with a thread?

On Tue, Jul 10, 2018, 3:49 PM MortimerMcMire [e-mail]
wrote:

I get the error again when I add astar nodes, and even more errors when
objects try to find connections.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/8691#issuecomment-403960807,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ANlKIK_wqj57DqbGTGwxYle4MPndU0I4ks5uFRNLgaJpZM4NTglu
.

[reduz]

@ianscottcamp Calling add_child from a thread will most likely cause unfixable instability. I suggest you still use call_deferred, but do something like calling a function of your own and pass an argument with an array containing all the objects you want to add, so it's just one call.

[reduz]

@ianscottcamp alternatively you can use servers directly instead of nodes, those work perfect if you call functions from multiple threads

[reduz]

AStar and Navigation are problematic, because while it may make sense for many to use it from a thread, it's an algorithm that requires a lot of working memory (which is optimized by storing this in the structure itself). This makes it thread-unsafe.

This would need some discussion on how it could be made work better from threads without the significant performance cost of allocating those structures all the time, but I suggest opening a new issue.

I will close this though, as the original issue never reappeared.

[efhilton]

I'm seeing this in 3.2.2. I have a thread that creates/adds Nodes. I've been adding locks everywhere that my Thread executes. But the problem is still there. I'm using C#.

[ZackingIt]

Ditto --
I have the variant

ERROR: remove: Condition "p_elem->_root != this" is true.
   At: ./core/self_list.h:84

pop up every so often and basically makes Godot unusable.

[Calinou]

@ZackingIt Please open a new issue with a minimal reproduction project attached.

[ZackingIt]

I wanted to add that disabling physics multi-threading seems resolve this issue, OR making sure to connect a signal as "deferred" if you are using multi-threading and that signal around a physics process (i.e., _body_entered).