The process remains after closing browser since version 92

[x5ERZzk]

Hello, Since version 92 of Ungoogled Chromium the browser process sometimes doesn't exit for a few minutes after closing the browser's window. As a consequence I cannot start the browser again after closing it. It usually happens once in few launches. This has been tested on a clean profile(s), on Windows 10 20H2 and 21H1, on physical hardware and on a virtual machine. I am using binaries from https://github.com/macchrome/macstable/releases (so I really apologize if I shouldn't report this issue here; however builds prior to version 92 close fine). The regular chromium builds (I have tested a few - versions 93 and 94) from https://storage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Win_x64/ work fine (even with the same reused profile). I have not noticed the same issue on Arch Linux (using binaries from chaotic-aur repository). Does anyone have a similar problem? Does anyone have such problem with their own builds? Thanks!

Steps to reproduce:

1. Start the browser (can be on a clean profile, it doesn't matter)
2. Close the browser.

All 'chrome.exe' processes should be terminated within a second or so, but remain for a few (around 3) minutes.

[Nifury]

Does anyone have a similar problem? Does anyone have such problem with their own builds?

Yes and yes. It seems the browser would hang at WaitForSingleObject for a few minutes, but I couldn't locate the root problem.

[tomasz1986]

I've also encountered this problem plenty of times. Normally, when I close the browser using the "X" button, it does seem to exit correctly most of the time. However, if the browser has been launched by clicking a URL (e.g. in Thunderbird), then it will always hang when trying to close it.

[UngoogledUsers]

The task persist and appears again when killing it in task manager. does anyone else have this?

[teeminus]

Can you please test with the latest release of the problem still exists?

Do you know how to reliably reproduce the problem?

@Nifury How did you troubleshoot the problem? Maybe I can continue your investigations.

[Nifury]

@teeminus Yes it still exists with the latest release.

Here is how I reproduce this issue:

1. Start the browser and open any webpage (e.g. google.com)
2. ALT+F4 before the webpage is fully loaded.

This can trigger the issue 80% of the time. If you launch the browser with MSVC and trigger the problem, you can pause the process and see where it hangs. Though it's hard to trace back who creates this waitable event and who is responsible to release it.

[teeminus]

I managed to reproduce the problem by opening and immediately closing the browser (latest release). I tried two machines but could only reproduce it on one of them...

[Nifury]

I was able to narrow down the problem but still don't have a clean solution yet.

https://github.com/chromium/chromium/blob/16f8dbf1595443282c716d2db20f8104afbb5c71/content/browser/storage_partition_impl.cc#L2377-L2380

  if (pending_tasks_.empty()) {
    std::move(callback_).Run();
    delete this;
  }

Two of the tasks task a long time to finish, impeding the closing process. Here are the two tasks (removing these two tasks solve the issue but with unknown side effects): https://github.com/chromium/chromium/blob/16f8dbf1595443282c716d2db20f8104afbb5c71/content/browser/storage_partition_impl.cc#L2521-L2541

What's common in these two tasks is that they all use AsyncCall which posts tasks to g_storage_task_runner. My best guess is that the corresponding worker thread is not woken up properly, so the tasks in the queue are executed only during the next periodic check.

[teeminus]

Maybe @Ahrotahn has an idea.

Or can we somehow discuss the problem with the chromium folks?

[Ahrotahn]

It looks like this is related to the Attribution Reporting API which happened to have started migration from it's predecessor in version 92.

This is something that should be handled by the privacy sandbox (which we disable), but it has individual feature flags outside of those options.

See if disabling both ConversionMeasurement and PrivacySandboxAggregationService resolves the issue. You should be able to launch with --disable-features=ConversionMeasurement,PrivacySandboxAggregationService to test.

I'll have to add an update to the privacy sandbox patch to disable those next time I get the chance.

[Nifury]

@Ahrotahn Yes, works like a charm!

[PF4Public]

Is this code Windows-only? I don't remember having anything similar on Linux.

[Ahrotahn]

It's not windows-specific, and I also had no issues with this on linux. I can only speculate that there is some platform-specific code elsewhere that comes into play or maybe differences in how the compiler handles things on windows.

[x5ERZzk]

I apologize for late reply. For me the issue is gone. Thank you wholeheartedly @Ahrotahn