3.2 Bug - NAN Error randomly spams console, then crashes

[tobiblender]

Godot version:
3.2 stable
OS/device including version:
win8 64 bit - geforce GTX 970 - i7 4790K
Issue description:
this Error spams the console in every frame - this randomly starts at some point of my game

_E 0:00:32.469   instance_set_transform: Condition "Math::is_nan(v.x)" is true.
<C++-Quellcode>servers/visual/visual_server_scene.cpp:601 @ instance_set_transform()_

ive integrated the RigidBody LookAt (look_follow) Method from the godot tutorial here
https://docs.godotengine.org/en/3.2/tutorials/physics/rigid_body.html

i just changed the target_position to
self.get_global_transform().origin + state.get_linear_velocity()

heres the changed look_at code for reference

func _integrate_forces(state):
	if AI_driving == false:
		if in_air == true and state.get_linear_velocity().length() > 10:

			var target_position = self.get_global_transform().origin + state.get_linear_velocity()
			look_follow(state, get_global_transform(), target_position)

func look_follow(state, current_transform, target_position):

	var up_dir = Vector3(0, 1, 0)
	var cur_dir = current_transform.basis.xform(Vector3(0, 0, 1))
	var target_dir = (target_position - current_transform.origin).normalized()
	var rotation_angle = acos(cur_dir.x) - acos(target_dir.x)

	var interpolate_frames = 90
	state.set_angular_velocity(up_dir * (rotation_angle / state.get_step() / interpolate_frames))

this code does however NOT change the location vector
but if enabled it produces the error NAN 1.#QO

so i stopped the game in the debugger if it happens - and found this:

the location vector becomes NAN - but only if the code above is active.
But the code does NOT mess with the location... so i dont see a reason.
Also i check if velocity > 10
So there cant be a division by 0 from that...

ive also checked my whole project for divisions by zero
because i read thats the main cause of NAN 1.#QO

since 3.2 i have this same error had many times in my project for other reasons that i have fixed... same project in 3.1.2 worked flawless.
I really think theres something wrong with an underlying C Code...
The error also shows in some other random cirumstances too.

As far as i can see - there is a bug - because i code some pretty solid simple things in GDscript and the error pops up randomly.
sometimes even without changing something in my code. just because i add a new object, node or something.
Things like this happens a lot since 3.2 - some vars and values seems to get mixed up for some unkown reason.
Ive got a feeling maybe it has to do with multithreading or something like this... but i am not a coder... so i dont know.
My Game was very stable and bug-free in 3.1.2
Now - after porting it to 3.2 its a buggy mess :) especially if i change or add something new, random unrelated errors and problems pop up... its strange.
There was no such problem in 3.1.2 - if ive had a problem it was always my code - now in 3.2 its often unclear where the problems come from.

BTW: cant the C++ Code not show us the GD-Script-Line where the problem comes from???
this would be soooo handy :)

Steps to reproduce:
no clue - its so random - it happens out of the blue - if i change my code or add a node etc...
Minimal reproduction project:
i cannot make a special one - and i cant give my project away puplicly
if a dev needs my project to tackle the bug - i can maybe share it privatly to this dev

and pls dont get me wrong - i really love godot - its a wonderfull gameengine!!!
peace out :) tobi

[tobiblender]

happend randomly again with this simple code - there should not be NAN

	var arc_scale = self.transform.origin.distance_to(target_car.transform.origin)
	arc_scale = arc_scale / 2
	self.scale_object_local(Vector3(1,1,arc_scale))

[tobiblender]

how can this simple code produce THIS ????

   At: ./core/math/octree.h:567
ERROR: move: Condition "!common_parent" is true.
   At: ./core/math/octree.h:901
ERROR: move: Condition "p_aabb.position.x > 1e15 || p_aabb.position.x < -1e15" is true.
   At: ./core/math/octree.h:834
ERROR: Octree upper size limit reached, does the AABB supplied contain NAN?
   At: ./core/math/octree.h:567
ERROR: move: Condition "!common_parent" is true.
   At: ./core/math/octree.h:901
ERROR: Octree upper size limit reached, does the AABB supplied contain NAN?
   At: ./core/math/octree.h:567
ERROR: move: Condition "!common_parent" is true.
   At: ./core/math/octree.h:901
ERROR: instance_set_transform: Condition "Math::is_nan(v.x)" is true.
   At: servers/visual/visual_server_scene.cpp:601
ERROR: instance_set_transform: Condition "Math::is_nan(v.x)" is true.
   At: servers/visual/visual_server_scene.cpp:601
ERROR: instance_set_transform: Condition "Math::is_nan(v.x)" is true.
   At: servers/visual/visual_server_scene.cpp:601
ERROR: instance_set_transform: Condition "Math::is_nan(v.x)" is true.
   At: servers/visual/visual_server_scene.cpp:601

[clayjohn]

Is your OS 32 bits? Also please post your hardware specs.

[tobiblender]

win8 64 bit - geforce GTX 970 - i7 4790K

[tobiblender]

the problem is this
self.scale_object_local(Vector3(1,1,arc_scale))

i printed the arc_scale varible to the console
the numbers are fine
16.355322
19.267458
16.333195

but somehow - acording to the errors posted above - this is producing AABB values that are wrong
the scale of my object is 1,1,1 ... everthing is standard

AND WHAT is that mean ???
At: ./core/math/octree.h:567
ERROR: move: Condition "!common_parent" is true.

thx.

[clayjohn]

I can't reproduce your issue by copying the script you provided.

Please put together a minimal reproduction project that reproduces this error and upload it here. You don't need to upload your project. In fact, it is better that you try to create a minimal project. So the smallest project that you can that reproduces this issue.

[tobiblender]

thanks for your help so far
i have done 4 minimal projects for my 4 other issues.... nobody looked at it yet... so i dont know.

somethings wrong with 3.2 deep down there... 3.1.2 was nice... had no problems with that

can i send you my project directly somehow... so you can have a look?

[tobiblender]

are there nightly build of godot 3.2 or something like this?
so i can test with a newer build? maybe it has allready been fixed.... (fingers crossed) :)

[clayjohn]

No, I don't have any knowledge about the physics code. Please post it here so that a contributor can pick it up.

A user produces nightly builds here https://hugo.pro/projects/godot-builds/

[tobiblender]

thank you for the link :)
is that the 3.2 branch or 4.0 ???

and no... i cannot share my project publicly... sorry

[tobiblender]

if i do
self.set_scale(Vector3(1,1,arc_scale))
or
scale = Vector3(1,1,arc_scale)
instead of
self.scale_object_local(Vector3(1,1,arc_scale))

the errors are gone!

[KoBeWi]

Can anyone still reproduce this bug in Godot 3.2.3 or any later release?

If yes, please ensure that an up-to-date Minimal Reproduction Project (MRP) is included in this report (a MRP is a zipped Godot project with the minimal elements necessary to reliably trigger the bug). You can upload ZIP files in an issue comment with a drag and drop.

[qarmin]

Closing due lack of response.
Without minimal project it would be very hard to find cause of this issue(or even reproduce bug)