-
-
Notifications
You must be signed in to change notification settings - Fork 22.3k
Improve script backtrace print in crash handlers #106139
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
Improve script backtrace print in crash handlers #106139
Conversation
Also fix the editor crash handler message for bug reports not properly using the `.editor` override.
As a side note, I'm not sure I'm fully sold yet on how this looks like: My first thought seeing this was that the indentation and gray color for the GDScript backtrace were not intentional. Thinking about it more, I guess the intent is to show that this GDScript backtrace is directly related to the red "ERROR" print, which makes sense. But it blending with the "at:" location for the error looks a bit weird to me. It might just be a matter of getting used to it, it kind of makes sense as is too. Maybe a slightly lighter gray while keeping the indentation may help it stand out from the C++ location? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't tried running it, but the code LGTM.
I guess the intent is to show that this GDScript backtrace is directly related to the red "ERROR" print, which makes sense.
Yes.
But it blending with the "at:" location for the error looks a bit weird to me.
Agreed. I don't really like it either, but I struggled to think of a better alternative without changing the formatting of the at:
stuff in some way. The current format at least seemed preferrable to not indenting the backtrace at all.
But yeah, maybe you're on to something with the lighter color.
It seems like currently we only support 3-4 bit colors: So there's no other shade of grey to use. We already use red, yellow, magenta and cyan, so only green and blue are left. Here's a try with green (Konsole): but this starts looking like the flag of Hungary :P Let's leave that for later bikeshedding. But I wonder whether we could start using 8-bit or 24-bit colors for our rich text printing, this might still be plenty enough for the terminals we aim to support, and others could just be without colors. 24-bit colors would mean we could support any hexadecimal code in |
Truecolor ANSI codes are already supported in 256-color codes should be preferred for portability, as macOS Terminal.app supports 256-color but not truecolor (even in macOS 15). |
Thanks! |
Also fix the editor crash handler message for bug reports not properly using the
.editor
override.Before this change,
-- END OF SCRIPT BACKTRACE --
would always be printed, even if it's a pure C++ crash with no script backtrace. That's becauseScriptServer::capture_script_backtraces
is never empty (unless there's no script language compiled in) as it includes empty backtraces for languages with no backtrace.I moved that end message to the inner loop so it's only printed if each specific backtrace is non-empty, and while at it I included the language name in that message.
Before
C++ only crash:
Crash originating in GDScript (
OS.crash()
):After
C++ only crash:
Crash originating in GDScript (
OS.crash()
):