Crash when calling std::cout in gdextension constructor

[Vantskruv]

Tested versions

Not reproducible in 4.1
Reproducible in 4.2

System information

Arch Linux 6.6.4-arch1-1 (64-bit)

Issue description

Crashing Godot if std::cout is called in a C++ class constructor using gdextension.
The call can be as simple as:
std::cout << "Hello World\n";
Removing it, Godot starts up.

Other calls to std::cout, which is not call in any initialization, I guess will just crash the application when running it from Godot.

================================================================

handle_crash: Program crashed with signal 11
Engine version: Godot Engine v4.2.stable.arch_linux
Dumping the backtrace. Please include this when reporting the bug to the project developer.
[1] /usr/lib/libc.so.6(+0x3e710) [0x7f178c56f710] (??:0)
[2] std::ostream::sentry::sentry(std::ostream&) (??:?)
[3] std::basic_ostream<char, std::char_traits<char> >& std::__ostream_insert<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*, long) (??:0)
[4] /media/ntfsevo/Utveckling/GODOT4/GoKam/GoKam/bin/libgdgokam.linux.template_debug.x86_64.so(+0x2630a) [0x7f1789c1e30a] (??:0)
[5] /media/ntfsevo/Utveckling/GODOT4/GoKam/GoKam/bin/libgdgokam.linux.template_debug.x86_64.so(+0x381fb) [0x7f1789c301fb] (??:0)
[6] /media/ntfsevo/Utveckling/GODOT4/GoKam/GoKam/bin/libgdgokam.linux.template_debug.x86_64.so(+0x13cd9) [0x7f1789c0bcd9] (??:0)
[7] /media/ntfsevo/Utveckling/GODOT4/GoKam/GoKam/bin/libgdgokam.linux.template_debug.x86_64.so(+0x38ee0) [0x7f1789c30ee0] (??:0)
[8] /usr/bin/godot(+0x3d4444d) [0x55965b57f44d] (??:?)
[9] /usr/bin/godot(+0x2c49141) [0x55965a484141] (??:?)
[10] /usr/bin/godot(+0x2c4ca6d) [0x55965a487a6d] (??:?)
[11] /usr/bin/godot(+0x683cbc) [0x559657ebecbc] (??:?)
[12] /usr/bin/godot(+0x582f5b) [0x559657dbdf5b] (??:?)
[13] /usr/lib/libc.so.6(+0x27cd0) [0x7f178c558cd0] (??:0)
[14] /usr/lib/libc.so.6(__libc_start_main+0x8a) [0x7f178c558d8a] (??:0)
[15] /usr/bin/godot(+0x58fd95) [0x559657dcad95] (??:?)
-- END OF BACKTRACE --

================================================================

Steps to reproduce

Add a call to std::cout in your gdextension constructor.

Minimal reproduction project (MRP)

gdtest.zip

[AThousandShips]

Does it happen if you use the helper function for it? UtilityFunctions::print("Hello World");

[Vantskruv]

No crash when using UtilityFunctions::print("Hello world")

I am currently converting my cpp sources to use godot:s print function instead of std::cout, there is quite some lines and formats to change.

[AThousandShips]

Can you also try with printf?

[Vantskruv]

printf works. :)

[AThousandShips]

Then I think this can be closed, we don't recommend using the standard library in general and don't think we do on the godot-cpp page either, can be a trap for some but we do provide proper printing methods (which also work with the editor) so I think this is out of scope for what we support

[Vantskruv]

So does that mean using standard containers such as std::vector, and other classes, is not recommended as well?

[AThousandShips]

Not for the engine at least, you're free to do what ever you like in an extension 🙂, but we don't provide any guarantees of safety in using these things as we don't test for them AFAIK

[Vantskruv]

Okay, thanks, for the help. I will see what I can do to limit as much as possible from std library.
I guess I am closing this now.

[AThousandShips]

Also, this might be due to error handling being turned off, which it is in both the engine and godot-cpp now days, and that's another reason to avoid the standard library as it depends heavily on errors

[Vantskruv]

I noticed that exceptions where not allowed aswell (error handling), as I am parsing some files and using std::stoi, which may throw things.

I added this line in SConstruct:
env.Append(CCFLAGS=["-fexceptions"])
to be able to catch exceptions.

I am using exceptions in some of my classes aswell.

I guess you want to avoid crashes and exceptions in Godot which is good, but that feels like impossible in C++ ...

Off topic, right now I am trying to export my app to Android, but it does not work as well as I thought, even if I am compiling the Android library, and installing the app on my phone without any problems, Godot complains about my library is missing.
I guess it may be Godot is more sensitive then I believed.

[AThousandShips]

You need to instead add disable_exceptions=False, and build the engine yourself with the same flag, see:

• Handling exception crashes editor/program godot-cpp#1326

This is probably what's causing this, you can't run error handling without changing these things

[Vantskruv]

Thanks.
I just want to point out, not sure if I should reopen this issue.
But I am using opencv, and opencv is using the std libaries internally.
This means I will not be able to use opencv with Godot at all.
This will be a major problem for me.

[AThousandShips]

Thats not really an issue on our end, please try with enabled exceptions, and see, but we're not able to guarantee support universally

[Vantskruv]

Then I guess we are quite limited using other libraries, hence OpenCV will not work because it is writing logs with the standard library internally.

But thanks anyway, I cannot request anything, as you are doing a great job with this awesome engine!
So we have to accept the limits ...
I can use 4.1 as for now though.

Using disable_exceptions=false does indeed remove the exception compile errors.

[AThousandShips]

Did you build the engine as well? Also are you using the correct version of godot-cpp?

[AThousandShips]

But importantly: we can't (and don't) provide any guarantees of compatibility in general, but if you identify a specific issue that can be solved then you should report that

But it needs to be specific, so if you identify some specific part of the code that makes using libraries hard then please report it, but in this case do so over here

[dsnopek]

Just a note on this issue since I hadn't seen it when it came up originally:

Using std::cout shouldn't cause a GDExtension to crash, and you shouldn't have to use Godot compiled with support for exceptions in order to do so. In fact, I've so far been unable to reproduce this crash.

There seems to be some difference in the environment of users who are experiencing this crash, and we should get to the bottom of what that is.

Let's continue working on this over on this godot-cpp issue: godotengine/godot-cpp#1326