-
-
Notifications
You must be signed in to change notification settings - Fork 21k
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
Comments
I tried to use |
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.
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.
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? |
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 |
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, Are you, by any chance, using the arguments |
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. |
Maybe it's a better name for the issue:
|
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. |
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.
But, If the game is executed from the editor, the exception is shown, but in a messy format.
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. TheNativeFuncs.godotsharp_internal_script_debugger_is_active()
method returns true when the app is launched from the command line, so it never does theGD.PushError(e.ToString());
, which is what we need as developer to know what happened. So, I guess the real fix is ensuregodotsharp_internal_script_debugger_is_active()
Steps to reproduce
_Ready()
method of any node./Applications/Godot_mono.app/Contents/MacOS/Godot --path .
Minimal reproduction project
no-exception-from-command-line.zip
The text was updated successfully, but these errors were encountered: