Repository: godot
Issue: Large amount of print_line causing lockup switching from Project Manager to Editor while debugging with Qt Creator
Labels: bug,topic:core,confirmed

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
<!-- Specify commit hash if using non-official build. -->
Godot 3.2.4 dev
Godot 4.0 master latest version df4fe11

**OS/device including version:**
Linux Mint 20
Intel Core i5-7500T
Intel HD graphics 630
QT Creator 4.13.3

<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->

**Issue description:**
<!-- What happened, and what was expected. -->
Issuing a large amount of `print_line`s from c++ causes freezes and lockups when running in a debugger from QT creator, but *only* when going through the transition from the project manager to the editor (not when running the editor directly with -e argument).
* Possibly a QT creator bug
* Possibly related to #43705?

**Steps to reproduce:**
I tried spamming `print` from gd script but it doesn't appear to cause it, I've only got it to work from c++.
e.g. In vulkan_context.cpp, add this spamming to the start of `swap_buffers`:
```
Error VulkanContext::swap_buffers() {
	for (int n=0; n<128; n++)
		print_line("swapbuffers?");
	
	if (!queues_initialized) {
		return OK;
	}
```
Now I start debugging the project manager from QT creator, choose a project, and it starts doing a swap_buffers every frame, and pretty soon freezes once you start opening menus (opening lots of menus (OS windows)) seems to be associated, I'll put more info as I find it.

## Debugger only?
* It does *not* seem to occur when running from the terminal, but only from the QT creator debugger. I've tested QT creator by spamming prints in a simple c++ program just in case it was a QT creator bug, and it seems to run fine. But that still doesn't mean it is impossible that it is QT creator bug.

* Also relevant, I set it this project to `log_to_file` in the project settings. I'll try turning that off and report back.
*EDIT* - Still occurs when `log_to_file` is off, so it doesn't appear to be that.

* Does not seem to occur when running in the same way from gdb in the terminal. So this again is pointing to QT creator or some timing / locking interaction with QT creator. I'll see if I can replicate it in 3.2, in case it is a regression in QT creator latest version.

## Problem due to print_line after cleanup?
Even more curious - something which puzzled me when investigating this (over 3 days), it doesn't occur when you use the `-e` argument to debug the project directly when running the debugger. It *only* seems to occur after transitioning from the project manager to the Editor.

This makes me wonder whether the problem is occurring due to print_line being issued (from c++) after something in the logging has been deleted or cleaned up, causing a corruption which exhibits when it then runs the editor. Or before? This theory would also tie in with gdscript prints not causing it.

It is a pretty crazy set of symptoms I'll admit. I first thought it was a bug in the GLES renderer I was writing, but it turns out to be nothing to do with it!

## Latest
* It occurs in 3.2 as well!! It had never happened before, presumably because it only occurred with a small margin of conditions, or maybe a new QT creator bug triggered by recently upgrading OS and QT.
* It does *not* occur in qt creator when I choose the 'run in terminal' option.

So my current theory is this is either a QT creator bug (or even possibly OS?), or if a Godot bug, a race condition which only triggers in specific circumstance. If it really is this rare then perhaps we can ignore it. But it wouldn't hurt to look through print_line and see if there is anything suspicious.