godot-4 branch: Stopping debug mode in editor often does not close gdcefSubProcess.exe on Windows 11

[TheSilentFog]

I just discovered that running gdcef on windows 11 from the editor and subsequently stopping the debug run often results in the browser background process to not close at all.

This behaviour seems to be unconsistent from what I do with the open browser inside the godot run window.

I had an instance of this problem where after even some failed runs on godot, due to code errors, there were 5 ghost browser processes using almost all of my cpu. I had to kill them one by one on the task manager.

Shouldn't be there, inside the browser process, a ping system which checks if the godot process that created it is still alive to prevent edge cases?

I was trying things out on the 2D demo project.

[Lecrapouille]

@TheSilentFog, in nominal cases, whatever the operating system you are using, if you see multiple cef processes, this is normal: CEF creates many forks of itself (Firefox also do the same things).

If these processes are not correctly killed, this is an issue. I checked on Linux, I do not have this issue. @raphipod can you check (I do not have windows).

[Pastew]

Hello, I encountered the same problem on Windows 10 and v0.10.0-godot4

Reproduce steps are easy:

1. Hit Play in Godot, wait until browser loads website.
2. Hit Stop.
3. You should have 1 ghost process in Task Manager

Repeat steps to get more ghost processes.

[raphipod]

@TheSilentFog, in nominal cases, whatever the operating system you are using, if you see multiple cef processes, this is normal: CEF creates many forks of itself (Firefox also do the same things).

If these processes are not correctly killed, this is an issue. I checked on Linux, I do not have this issue. @raphipod can you check (I do not have windows).

That's correct. It works properly on Linux, weirdly enough.

I have yet to test it on Windows specifically, but on my prior debug tests I also noted this and thought it was normal as CEF uses multiple threads for rendering/drawing, audio, network etc.

AFAIK, the CefShutdown() function should be executed in the thread where CefInitialize() should've been called beforehand, so that all subprocesses can get notified. Which get's executed here.

I must admit I don't know much C++, so I am most likely not qualified enough for this issue ;)

@TheSilentFog did you have an antivirus running in the background at the time of testing? It could be that some subprocesses are getting flagged/quarantined by an AV.

[Lecrapouille]

I know That GDCef instance is not destroyed. Maybe because Godot is still using it when inside the editor (ref counter). It is released when Godot ends. On Linux forks are killed I guess artificially. So maybe in Windows there is not such security

[Pastew]

1. I noticed it doesn't happen every time.

But when it happens, after I hit Play button in Godot I see many gdcefSubProcesses under Godot process:

And after I hit Stop one of them seems to be somehow detached from parent process and stays alive forever in "Background processes" category in Task Manager.

2. Closing Godot Editor does not kill this gdcefSubProcess.

[pimhakkert]

I concur, it does not happen every time, but it can quickly stack up. Has anyone had issues with this regarding a production build besides during development? If so then we need to expedite a fix. My PC (windows) came to a grinding halt because these subprocesses were taking up my entire CPU during development.

[Lecrapouille]

Yes this is a real issue @face-hh https://youtu.be/37ISfJ2NSXQ?feature=shared&t=446 noticed it :) @eliopark-nsuslab have you idea ? I think probably a conflict between Godot's RefCount and CEF's RefCount. On Linux I do not have such zombies exe running.