Fatal internal error sporadically: "_logic_balance: FATAL: Condition "A->num_children != 2" is true."

[BevanFindlay]

Godot version:
3.3.stable.official

OS/device including version:
Windows 10 20H2, GLES3, Intel HD Graphics 520

Issue description:
I have a pretty complex project that I have been building in parts, and I have just connected my scene for generating planets to the one that manages the wider space, such that the Space scene instances a child of the Planet scene, sets its parameters, then gets it to generate a planet surface. To quit back from the Planet scene to the Space scene, there is a button on the Planet scene that calls queue_free(). I change the active camera between the scenes (and the world environment, though I'll probably move that to be local to each camera instead). Most of the time this works fine, but sometimes after I have opened then closed several planets, the project will crash, generating the following error to the output window:

ERROR: _logic_balance: FATAL: Condition "A->num_children != 2" is true.
   At: ./core/math/bvh_logic.inc:82

I tried googling this, but couldn't seem to find anything. Is there anyone out there familiar with the internals of the Godot engine enough to give me some hint on what might be going on here, or where to start looking? Being that it's part of a relatively complex project, it's probably not going to be easy to get a minimal test project if I'm not even sure what part(s) of the code are causing it. I did wonder if maybe I was leaving a file open somewhere, or doing something wrong with freeing resources, but couldn't see anything wrong when I looked for these.

Not sure if it's relevant, but occasionally I spot a minor graphical bug in the Space scene before it crashes (a strip of some stars [PointMeshes] disappear momentarily), and the opening/generating of a Planet scene will take longer if it is going to crash - as if it's getting stuck on something before it fails.

Any pointers on where to start with solving this?

I looked at the code listed (core/math/bvh_logic.inc) but the only help that gives is that it is apparently to do with physics logic. I do use raycasting into the 3d world in both scenes, so could it be something like that breaking with a half-built scene? I have no idea what part of my code would be hitting this, as its not giving me any friendly Godot error that would help in debug tracing - it just exits.

TIA!

Steps to reproduce:
Still trying to isolate.

Minimal reproduction project:
As mentioned, I still haven't been able to isolate it enough to identify the exact cause. Some help with where to start looking might help me to narrow it down.

[Calinou]

This is likely a regression from the new BVH in Godot 3.3. As a workaround, you can disable the BVH in the Project Settings.

[lawnjelly]

Am having a look, there are a couple of possibilities:

• Bug in this rebalancing / something is corrupting the tree
• Given your scenario, there could be a race condition, if the BVH is being modified and accessed from more than one thread (it is not currently thread safe). Please let us know anything that could be causing multithread access - raycasting while building a scene in another thread could indeed be problematic.

Firstly it would be good to clarify, are you using Godot physics or bullet? The BVH can be used for rendering rendering/quality/spatial_partitioning/use_bvh and Godot physics physics/3d/godot_physics/use_bvh. If you are using bullet then it must be the render tree (by a process of elimination).

This will probably be difficult without a minimum reproduction project but I'll see if I can work out any avenues for this scenario to occur I have missed (especially with the root node of the tree, which is a special case. It may even be that replacing the CRASH_COND with an ERR_COND is the right fix, but the graphical glitch may be related to some kind of corruption).

If you cannot simplify the project at all, and don't want to share it publicly, another possibility is to email it to me privately or a link. We've had to do this for a few issues for games that couldn't be reduced to a min reproduction project.

I did see another report of a similar visual issue with the BVH (maybe on reddit), but with no reproduction project I couldn't investigate, so I was aware of at least one existing bug, this may be the same one.

[lawnjelly]

Any help with a reproduction project would be greatly appreciated BTW. We have one for #48790, which is likely the same bug, but it doesn't seem to exhibit on my machine with that project.

[BevanFindlay]

Is there a way I could send you the project privately? That way I'm not putting up my entire WIP game project. :-)

[lawnjelly]

Is there a way I could send you the project privately? That way I'm not putting up my entire WIP game project. :-)

Yup sure, you can send me a private message on twitter (lawnjelly) or godot discord (lawnjelly) or godot developer chat (https://chat.godotengine.org/) lawnjelly. There are I think a lot of file hosting websites where you can send a private link to someone, that is what people usually do.

[lawnjelly]

I have now got some test builds available in the linked PR #48892. Please if anyone gets these BVH visual bugs, try out the test builds following the instructions in the PR. This will hopefully enable us to pin down the problem and fix it.

[lawnjelly]

Just to keep this updated, Bevan has kindly sent me the project and I've got it working, but again I can't seem to replicate it here on my Linux machine. @pouleyKetchoupp did try the other similar issue #48790 on windows last night, but again he couldn't replicate it either.

We also couldn't find any problems threading wise in the BVH (we tested with a mutex and it never got contended) although that doesn't guarantee there wouldn't be such a problem on your systems that are exhibiting the error.

I think for now we will merge a small fix to deactivate (hiding) which could have been the cause, and have to wait to see if someone comes up by chance with a minimum reproduction project that it shows more consistently on.

[lawnjelly]

We have identified a problem in the scenario_owner in VisualServer in Godot 4.x (#49501) where a similar BVH bug was caused by accessing a scenario after it had been freed. It is just possible something similar is happening in this issue, as the method for accessing a valid scenario was very 'improvised' (as I'm not very expert with the scenario lifetimes, this is really reduz area) and I was grabbing it from an instance in VisualServerScene::update_dirty_instances().

I'm trying to see whether this can be improved.

[akien-mga]

Is this still reproducible in 3.5 beta 5 or later?

[akien-mga]

No answer, and we don't have a clear way to try to reproduce it, so closing for now. Please comment if you can still reproduce it.

[BevanFindlay]

Hi, sorry it took me a while to get back to this. Life getting in the way and all that. I cannot reproduce the error in 3.5 beta 5 (though because it was kind of sporadic, I am also having trouble re-creating it back in 3.3 as well). Happy for this to stay closed. Much appreciate your input and help. Thanks.