Terminal color not properly restored after exiting

[QuadnucYard]

Compare:

[Rust]      Deinit level Editor
[Rust]      Deinit level Scene
[Rust]      Deinit level Servers
WARNING: 55 RIDs of type "CanvasItem" were leaked.
     at: _free_rids (servers/rendering/renderer_canvas_cull.cpp:2178)
ERROR: 17 RID allocations of type 'N10RendererRD14TextureStorage7TextureE' were leaked at exit.

[Rust]      Deinit level Editor
[Rust]      Deinit level Scene
[Rust]      Deinit level Servers
WARNING: 55 RIDs of type "CanvasItem" were leaked.
    [Rust]      Deinit level Editor

It seems that the terminal color will not be restored unless a stacktrace from cpp is given.

Btw, is there any way to check what was leaked?

[Bromeon]

Is this a problem that only happens with godot-rust? What if logs are printed from GDScript or the editor?

[QuadnucYard]

I called panic!() in process of SceneTree. The application may spontaneously terminate after several cycles (around 4), or continuously run and print error messages until I shut the application window. This issue arises in the latter scenario.

I guess that the process is terminated before a closing color control sequence is printed.
Maybe this is attributed to godot cpp rather than gdext.

A simple solution: manually print "\x1b[0m" somewhere, such as on_level_init.

[Bromeon]

But did you try reproducing it without godot-rust, just in GDScript? That would help us determine if it's something to be fixed in Godot or our Rust binding.

[QuadnucYard]

But did you try reproducing it without godot-rust, just in GDScript? That would help us determine if it's something to be fixed in Godot or our Rust binding.

Sorry for a late supplement. I conducted more experiments (each a few times), including godot-rust and GDScript, running in editor or running the exported application.

As for GDScript, I add a null + 1 like expression to the _process of a custom MainLoop and a script attached to the root node. When running in Godot editor, the exception is always caught, no error message printed to the terminal that starts Godot.

After exporting, however, there's always no problem with the terminal color, regardless of panic source.

In short, I could only reproduce the issue when the program is running in the active Godot editor and panic in rust code.

It is possible that this issue exists in all extensions, not just gdext. I can't provide a more extensive experiment at the moment.

I think we can just go forward and close this issue.

[Bromeon]

I think it's a fair issue, but I suspect it could have to do with the GDExtension API integration. godot-rust generally does no color formatting outside unit tests, and instead delegates to godot_print! and godot_error!. But it could be that in the event of a panic, those are not properly "closed".

What do you think is the easiest for me to reproduce this? Does the problem happen if e.g. in the dodge-the-creeps example, we add a panic! in some process() method? Or even earlier, so it doesn't even start?

---

Btw, is there any way to check what was leaked?

I missed this before, you can run Godot with --verbose and it should give you more detailed info about the leaked elements.

[Bromeon]

@QuadnucYard could you answer this?

What do you think is the easiest for me to reproduce this? Does the problem happen if e.g. in the dodge-the-creeps example, we add a panic! in some process() method? Or even earlier, so it doesn't even start?

[QuadnucYard]

@Bromeon Sorry for bothering so long. After thorough experiments, it seemingly has nothing to do with gdext.

The simplest reproduction is to load a packed scene and let it leak. Then close the window.
There is a certain probability that the warning message isn't fully printed to the terminal, causing abnormal color.

load("res://Mob.tscn").instantiate()

So let me close this issue. If the problem still exists in the latest version of Godot, I'll report it to godot then.