Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

C# exception stacktraces are not shown when app is executed from editor command line #68662

Closed
avilches opened this issue Nov 14, 2022 · 9 comments · Fixed by #77377
Closed

Comments

@avilches
Copy link
Contributor

avilches commented Nov 14, 2022

Godot version

v4.0.beta4.mono.official.e6751549c / v4.0.2
(tried with .net6 and .net7, failing in both)

System information

MacbookPro with macOS Monterey 12.6

Issue description

If the game is executed from the command line and an exception is thrown from any C# godot method (_Process, _Ready...), the application crashes without showing the exception stacktrace. Not sure if exiting the application is the correct behaviour (in Godot 3 was configurable: stop on error or ignore error and continue), though.

image

But, If the game is executed from the editor, the exception is shown, but in a messy format.

image

It will be awesome if the stacktrace in the editor is printed splitting the lines to improve the readiness.

Finally, if you execute the application using a debugger (I'm using Jetbrains Rider), the execution flow finishes in the Godot.NativeInterop.ExceptionUtils.LogException() method. The NativeFuncs.godotsharp_internal_script_debugger_is_active() method returns true when the app is launched from the command line, so it never does the GD.PushError(e.ToString());, which is what we need as developer to know what happened. So, I guess the real fix is ensure godotsharp_internal_script_debugger_is_active()

Steps to reproduce

  1. Throw an exception inside the _Ready() method of any node.
public partial class node_2d : Node2D {
    // Called when the node enters the scene tree for the first time.

    public override void _Ready() {
        throw new Exception();
    }
}
  1. Launch the app using /Applications/Godot_mono.app/Contents/MacOS/Godot --path .

Minimal reproduction project

no-exception-from-command-line.zip

@avilches
Copy link
Contributor Author

I tried to use AppDomain.CurrentDomain.UnhandledException += (o, args) => { ... }, but the event handler is never executed. It looks like the Godot.Bridge.CSharpInstanceBridge class catches all the errors from C# game classes in the Call method.

@raulsntos
Copy link
Member

If the game is executed from the command line and an exception is thrown from any C# godot method (_Process, _Ready...), the application crashes without showing the exception stacktrace

No, you did get a stacktrace but a native one because the crash occurred in C++'s side. This is not intended, a C# exception should not cause a native crash.

The NativeFuncs.godotsharp_internal_script_debugger_is_active() method returns true when the app is launched from the command line

That doesn't sound right. Launching from the command line the script debugger should not be active. Trying to access the debugger when there isn't one is likely causing the crash here since it's probably trying to access something that is null.

But, If the game is executed from the editor, the exception is shown, but in a messy format.

If the game is executed from the editor, then the debugger should be available and therefore the crash won't happen. About the exception format, this was already reported in #67451.


Also, I can't reproduce this in Linux so maybe this is specific to Mac?

@avilches
Copy link
Contributor Author

Not sure about where the native trace comes from, but the exception is happening in the C# side. I've just recorded this video, running the app from Rider with debug. The execution stops in the exception, and executing step by step, it finishes in the godotsharp_internal_script_debugger_is_active() and it tries to send the native trace to the editor. But the C# exception is there too. So it looks like the native stacktrace comes from nowhere...

Screen.Recording.2022-11-14.at.21.46.04.mov

@raulsntos
Copy link
Member

Sorry, I think I didn't explain myself properly. It wasn't my intention to say that the C# exception wasn't happening, it does happen and then the C++ code crashes when trying to handle it. So, because the crash happens in C++'s side you get a native stacktrace. Just to be clear, the native crash is a bug and it's not meant to happen, the intended behavior is to print the C# exception to the console but it crashes before it can do that.

When a C# exception is thrown in user code, we send it to the script debugger if it's active; otherwise, we print it. Since you are launching from the command line the script debugger is not active so it should print the C# exception to the console. For some reason, godotsharp_internal_script_debugger_is_active is returning true so it's trying to send the exception to the script debugger instead. However, since there isn't a script debugger, it's likely going to try to access null at some point which is what's likely causing the native crash.

Are you, by any chance, using the arguments --remote-debug, --debug or -d when launching Godot from Rider?

@avilches
Copy link
Contributor Author

avilches commented Nov 15, 2022

Thanks for the explanation, I really appreciate it, now I have a better understanding what's happening: 1) C# exception, 2) godotsharp_internal_script_debugger_is_active returns true instead of false 3) the C# exception is sent to the editor 4) the editor is not present, so a C++ stacktrace is dumped. Again, thank you, I wish I know a little bit C++ so I can try to fix it myself :)

Regarding the question: no, I'm not using any of those parameters. Reach me by discord betauer#3353 or rocket chat (betauer) if you need me to test any change, branch or whatever.
image

@avilches
Copy link
Contributor Author

This is still happening in Godot 4.0.1-rc.1: running project from the editor shows the stacktrace in the editor, running the project from command line doesn't show the C# stacktrace and fails.

@avilches
Copy link
Contributor Author

Maybe it's a better name for the issue:

  • NativeFuncs.godotsharp_internal_script_debugger_is_active() returns true when there is no editor, like running the game from the command line.

@RedworkDE
Copy link
Member

Can not reproduce, regardless of how exactly I start the project, the exception is always just printed to the console. Using master 23394be and the official beta4 build (on windows), also did a quick test on a mac with some random build I had there e0de357, but no issues there either.

Tho I have had this crash myself in the past, when running editor code, but only when using custom builds.

Needs more testing to see what exactly the criteria for this crash are.

@avilches
Copy link
Contributor Author

I tried again with Godot 4.0.2, same error in MacOs Ventura 13.2.1 (Intel i7 Macbook 2017): running the project from command line (no editor) crashes with this dump:

================================================================
handle_crash: Program crashed with signal 11
Engine version: Godot Engine v4.0.2.stable.mono.official (7a0977ce2c558fe6219f0a14f8bd4d05aea8f019)
Dumping the backtrace. Please include this when reporting the bug to the project developer.
[1] sigsegv_handler(int, __siginfo*, void*)
[2] 2   libsystem_platform.dylib            0x00007ff805a2ac1d _sigtramp + 29
[3] 3   ???                                 0x0000000000000000 0x0 + 0
[4] JSON::get_data() const
[5] Object* ClassDB::creator<mono_bind::GodotSharp>()
[6] 6   ???                                 0x00000001248c413f 0x0 + 4908138815
[7] 7   ???                                 0x00000001248c3fe2 0x0 + 4908138466
[8] 8   ???                                 0x00000001248c10a3 0x0 + 4908126371
[9] 9   ???                                 0x00000001248c095b 0x0 + 4908124507
[10] 10  ???                                 0x00000001248b49d5 0x0 + 4908075477
[11] Object* ClassDB::creator<MobileVRInterface>()
[12] MultiplayerAPI::is_server()
[13] NavigationObstacle2D::get_radius() const
[14] ScriptInstanceExtension::_add_property_with_state(void const*, void const*, void*)
[15] Node::get_tree() const
[16] Node::get_tree() const
[17] Node::is_inside_tree() const
[18] Node::is_inside_tree() const
[19] 19  Godot                               0x0000000106a2096d Godot + 4643181
[20] RendererCompositorRD::_create_current()
[21] 21  dyld                                0x00007ff8056cd310 start + 2432
-- END OF BACKTRACE --
================================================================

If the project is executed inside the editor, the C# stacktrace appears properly in the Debugger -> Errors tab and the game execution continues, which is the expected behaviour.
image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants