Error "Unreferenced static string to 0: interface_added" on editor startup

[Abdul-AZ]

Godot version

9580769

System information

Archlinux 6.0.6-arch1-1 kernal, X11

Issue description

Hello
When starting the editor on the latest dev build I get these errors

ERROR: BUG: Unreferenced static string to 0: interface_added
   at: unref (core/string/string_name.cpp:131)
ERROR: BUG: Unreferenced static string to 0: interface_added
   at: unref (core/string/string_name.cpp:131)

I spent some time investigating this and I think this happens when the app tries to select the best GPU to use for rendering. Here is where I think the issue is:
In the detect_prime() in the detect_prime_x11.cpp file. There is a call to fork() on line 152.
As far as I understand, this call is supposed to make the sub processes try and make an X11 session then relay the best selected gpu back to the main process. I think the issue comes when these processes finish and exit() gets called. They try to free global memory(call global destructors) and thats where they run into this error and output it to console.

The reason I suspect this is because I ran the editor with gdb with -gdb-set follow-fork-mode child and the error only happens on the call to exit() on line 211 in detect_prime_x11.cpp in the sub process.

Removing the call to emit_signal() in text_server.cpp causes the error to not show up. I suspect that doing this causes the static string to not be allocated and thus does not show in the sub processes so no error because there is no call static object destructors.

I don't know why freeing the static object causes this error. If anyone could have a look at this to confirm that I am on the right track or if this is completely unrelated.
Thanks

Steps to reproduce

Start the editor on the latest commit with a dev build and observe terminal output.

Minimal reproduction project

No response

[Abdul-AZ]

One possible fix is to change exit(0) call on detect_prime_x11.cpp in line 211 to quick_exit(0) so that no resources are freed in the child process (this fixed the error). This shouldn't cause any memory leaks either. Does that sound like a sane solution?