An issue with get_direct_space_state() method being called from native script written in C++...

[Yar-Mukhamedov]

Dear Godot Engine developers,

I believe I have found a bug that prevents use of get_direct_space_state() from native scripts written in C++. I found no reports of this issue by others (however, it may actually have similar causes as issue #11913), thus I decided to create a new issue report. Below I will do my best to provide as much relevant details as possible.

Godot version: 3.1 Stable Release

Operating System: Windows 7 Professional 64 bit

Issue description: get_direct_space_state() called from C++ native script leads to crashes

Steps to reproduce:

1. Create a new native script by following tutorial at:
   https://docs.godotengine.org/en/3.1/tutorials/plugins/gdnative/gdnative-cpp-example.html
   (most of the bindings should work fine at this point);
2. Define (and register) _physics_process method;
3. In _physics_process method call get_direct_space_state(), e.g.:
   auto DirectSpaceState = get_world()->get_direct_space_state();
4. Create a scene and use native script created during previous steps there;
5. Attempt to run this scene, which should result in a crash.

Additional details:
Console output should contain following:
ERROR: get: Condition ' !res ' is true. returned: *res
At: ./core/hash_map.h:306

Problem, however, to the best of my knowledge is not in HashMap itself, but in bindings.

I studied source code of the bindings and of the engine to infer what causes the crash, as well as recompiled sources in debug mode to get more information from a backtrace. In both cases it lead me to line 1352, in function "get_instance_binding_data" in "modules/gdnative/nativescript/nativescript.cpp". I manually checked the content of "global_type_tags" and value returned by "p_object->get_class_name()".

The crash happens because "p_object->get_class_name()" returns either "BulletPhysicsDirectSpaceState" or "PhysicsDirectSpaceStateSW" (depending on the physics engine enabled in project settings), while "global_type_tags" does not have such an entry. It only has an entry for "PhysicsDirectSpaceState" (i.e. for the base class).

This seems strange because "global_type_tags" does contain other class names of classes relevant to bullet physics (e.g. BulletPhysicsDirectBodyState, BulletPhysicsServer), as well as class names of corresponding base classes. But there is no entries for "BulletPhysicsDirectSpaceState" or "PhysicsDirectSpaceStateSW", as well as no relevant entries for relevant internal (not bullet) 3D physics.

I am not sure if this was intended by design or if these classes were omitted unintentionally. Either way they are not present in "global_type_tags" HashMap, which causes the crash.

I believe that the simplest way to solve the issue would be to expose "BulletPhysicsDirectSpaceState" and "PhysicsDirectSpaceStateSW" (as well as all other relevant classes which are not yet exposed) via C++ bindings (which is not the case at the moment to the best of my knowledge). I am, however, not sure if this is preferable way to solve this problem. Therefore, I have several questions.

Questions:
Primarily, could you please confirm if this is a bug and not an intended behaviour?
Secondly, if it is indeed a bug, could you please let me know if there is a preferred way of resolving it?
Finally, could you suggest a good forward compatible workaround to this problem (if there is any) in order to make use of it until better solution gets implemented in the stable release?

With best regards,

Danial

[akien-mga]

CC @karroffel @BastiaanOlij

[karroffel]

Seems related to #27936

[jedobson]

This specific issue seems to be fixed if you build the current master branch. I was seeing it on 3.1.1 stable but after building master it went away.

[akien-mga]

Closing as it seems to be fixed already as per above comment.

[huhund]

In which version is this fixed? I'm still getting a nullptr with 3.2.1 and gdnative master pulled 9 April 2020.

More specifically, using 3d GodotPhysics returns nullptr for "get_direct_space_state()". While using 3d Bullet physics returns a working pointer.

Footnote: the silly thing is that I can't currently use Bullet physics because there is another bug in Bullet :/.

[huhund]

Is this commit? godotengine/godot-cpp@f100d7f I'll see if I have time to debug what is happening.