Open AbanoubNassem opened 3 years ago
Calinou
commented
3 years ago @AbanoubNassem Can you reproduce this in your project by doing the same operation in GDScript?
Also, it would be useful to have a minimal reproduction project available for troubleshooting.
AbanoubNassem
commented
3 years ago @Calinou
I have made a simple project to test : https://github.com/AbanoubNassem/godot-cpp-cmake/
please follow instructions there to build godot-cpp and library , after the build finishes, the output library should be inside the game folder , open godot project and link the library , after that just run the scene try to close the window it will hung then crash
Zylann
commented
3 years ago Looking at the crash dump, I dont see anything useful. It would be interesting if you could compile the bindings and your library in debug mode, and run your project using an actual debugger because it would likely be able to point out the full detailed call stack, rather than a cryptic crash (there are sooooo many people asking for help without doing any of that, it's kinda crazy).
Also a crash and a leak are different things, you reported a crash, but I dont see how you deduced the existence of any leak.
About the code:
namespace Library {
class World : public godot::Spatial {
GODOT_CLASS(World, Spatial)I'm surprised this even compiles. Spatial here is used without the godot:: namespace prefixed. In this macro it is used here:
https://github.com/godotengine/godot-cpp/blob/fda7ddd158b2d2ef6d7af7d509694415ec81d615/include/core/Godot.hpp#L110
You don't use godot:: here either https://github.com/AbanoubNassem/godot-cpp-cmake/blob/29f543ca757c85008edacb0ba029113344a7e6d1/library/src/sources/World.cpp#L10
Even though register_method is not even inherited, it's a regular function in the godot:: namespace, yet somehow we can use it without the namespace Oo
Now, based on what the title of this issue claims, I did a simple test myself by just adding the following CustomSpatial to a scene:
#include <core/Godot.hpp>
#include <gen/Spatial.hpp>
namespace yolo {
class CustomSpatial : public godot::Spatial {
GODOT_CLASS(CustomSpatial, Spatial)
public:
CustomSpatial();
~CustomSpatial();
void _init();
void _ready();
static void _register_methods();
private:
};
} // namespace yolo
/////////////////////////
#include "custom_spatial.h"
#include <gen/World.hpp>
namespace yolo {
CustomSpatial::CustomSpatial() {
}
CustomSpatial::~CustomSpatial() {
}
void CustomSpatial::_init() {
}
void CustomSpatial::_ready() {
godot::Godot::print("Ready");
auto world = get_world();
}
void CustomSpatial::_register_methods() {
godot::register_method("_ready", &CustomSpatial::_ready);
}
} // namespace yoloNo crash occurred.
However I was surprised to see that if I omit godot:: myself, compilation works fine... which isn't normal, isn't it?
Because the problem is, if I name my class World too... isn't it going to conflict with godot::World?
Anyways, I could not reproduce this by solely doing auto world = get_world() inside _ready(). I know there is your project but then it means the problem originates from something else (I'm too tired to investigate more atm).
AbanoubNassem
commented
3 years ago @Zylann
Looking at the crash dump, I dont see anything useful. It would be interesting if you could compile the bindings and your library in debug mode, and run your project using an actual debugger because it would likely be able to point out the full detailed call stack, rather than a cryptic crash (there are sooooo many people asking for help without doing any of that, it's kinda crazy).
well I completely understand you, but not all of us are 100% working on games and on Godot perticaulary , so for most of us it's test/try the Engine and see, if it fits our needs , and that is the case for me , I wanted to see if Godot and NativeScript are the best fit for me , without going to all this hustle!
Also a crash and a leak are different things, you reported a crash, but I dont see how you deduced the existence of any leak.
I completely understand that as well, the reason I stated it might be a leak , is this issue : https://github.com/godotengine/godot-cpp/issues/85 , also when I close the app , it hung and take a bit to close like trying to free some memory .
I have added godot:: to everywhere it should have been added , changed the World to CustomWorld everywhere , and still does the same thing : https://youtu.be/zvDQMKnY75E
AbanoubNassem
commented
3 years ago @Zylann @Calinou
I have attached a debug to it , and here is the result :
handle_crash: Program crashed with signal 11
Dumping the backtrace. Please include this when reporting the bug on https://github.com/godotengine/godot/issues
[1] 1 libsystem_platform.dylib 0x00007fff2037dd7d _sigtramp + 29
[2] 2 ??? 0x0000000000000000 0x0 + 0
[3] Object::can_translate_messages() const
[4] SceneTree::get_root() const
[5] SceneTree::get_root() const
[6] DefaultAllocator::alloc(unsigned long)
[7] DirAccess* DirAccess::_create_builtin<DirAccessOSX>()
[8] 8 libdyld.dylib 0x00007fff20353f5d start + 1
[9] 9 ??? 0x0000000000000009 0x0 + 9
-- END OF BACKTRACE --is this has any useful information ?
Zylann
commented
3 years ago It seems like this isn't at all from get_world then, more like some directory operation (which is strange cuz I see none of that in your code). Now I suspect version mismatch or some OSX-specific issue. But hard to tell what the call stack is really doing, or even where these stack frames belong to. SceneTree::get_root() is an inline getter so I dont understand why can_translate_messages or alloc surrounds it... usually debug builds show the associated cpp file as well, it seems incomplete... is this the entire call stack? Is your library and bindings built in debug mode as well? (if they are not, a debugger not only won't show the files, but it will also likely show optimized out call stacks which might not make sense)
About the namespace, I dont think it is the cause of the issue, rather a strange curiosity going on.
AbanoubNassem
commented
3 years ago @Zylann unfortunately it seems to crash outside the binding , Error :EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
here is the disassembly : https://gist.github.com/AbanoubNassem/a8cf6610d683a773808cb00dad0762f5
it crashes on line 87 , but I can't get any much information out of it 🤷🏻♂️
Zylann
commented
3 years ago Still doesnt help (at least for me, I can't read that). What I would do here is to compile litterally everything in debug mode and run it through a debugger. Is this what you did here? Because ideally the goal would be to get the full detailed C++ call stack with file names and lines, not a disassembly (also I don't have OSX to test this on the same platform)
calling
get_world()fromKinematicBodycausing crash possibly leak! , currently I'm calling it in the_readymethod :