Reporting silent errors in release builds

[m-radzikowski]

From what I've tested, runtime errors that are silently handled by Godot, like array out of bounds, are not visible in release builds and not reported by Sentry. Is this correct and is there any way to enable it?

Details

Godot silently "ignores" most errors in debug and release builds. For example this code:

var arr := []
print("oob ", arr[0])

will print oob <null> (unlike when running from the editor).

In debug builds, those are logged to file, and also intercepted and reported to Sentry.
In release builds however, there is no error log nor Sentry event.

This kinda undermines the idea of reporting problems, if only errors reported are those sent manually from the code, with either SentrySDK.capture_message() or push_error(), and crashes to desktop.

And this is the exact scenario as in Sentry video: https://www.youtube.com/watch?v=l2u1NQNWksQ (call("nonexisting_method") also is not reported in release build).

As far as I can say, the Logger _log_error is simply not invoked with such error in release builds.

So:

• Am I doing something wrong? I've tested on fresh project, Godot 4.6.1, Windows
• Is the only solution for proper reporting to use debug builds? Which is far from optimal for production.
• Or is this possible with custom template, similarly to stack traces?

If this is Engine limitation, I will open issue/proposal there.

[linear]

GODOT-168

[limbonaut]

@m-radzikowski Thanks for reaching out! I believe it's a Godot Engine issue. Looking into the issue, I can see that some GDScript errors are silently dropped by the engine's VM like the one you've pointed out. While digging through the sources, I noticed that some GDScript VM errors are guarded by DEBUG_ENABLED preprocessor conditionals, which makes them silently ignored in release builds. This affects some core GDScript language errors like Array OOB. We solely depend on the engine being truthfully reporting these issues via Logger interface, but some class of errors are simply dropped in release.

[m-radzikowski]

Thanks for looking into it. Yes, you are right, only editor and debug builds have DEBUG_ENABLED, release builds do not.

I've opened a proposal (14370), but I'm not sure how viable enabling errors in release/custom templates is. It may be that performance with enabled logs is so close to debug builds that using debug builds is just a proper solution here.

[limbonaut]

In my testing, only a class of GDScript language-specific errors are excluded in release builds. The logging system is actually fully functional, so any errors that happen within the engine subsystems (a large number of cases actually) are fully reported (ERR_* macros in Godot source code). Those are reported in release builds.

I don't think it's necessarily a good design to ignore just some errors. If it's a performance decision, then it's very selective in what gets reported. I'm not saying engine should crash for something like Array OOB, but pushing an error to the logging stream would be nice. It so happens, that some errors are only discovered in production. Godot debug builds also contain extra code related to real-time debugging such as client that listens to messages on TCP and responds by sending GDScript variable state, stepping through code, etc. It may be that the guarded part in the GDScript VM is simply an oversight.

[m-radzikowski]

Looking at the source code, it looks like all errors in GDScript specifically are behind DEBUG_ENABLED. So all OOB, assignments of nonexisting values, accessing null or freed instances, etc. in GDScript code. Generally everything in gdscript_vm.cpp. Thus it looks like a performance-related choice. So yes, errors originating in engine subsystems are separate and those are reported.

My proposal is to have a build flag that enables errors without enabling other debug features, thus minimizing performance cost. However, even thus maybe I could try making some progress on that, it's pretty close to the core of GDScript so some guidance and approval from maintainers would be needed first. So best to chip in there in order to work out a functional solution so it can be implemented, I guess ;)