Version: M55 and newer
OS: Windows 10 64-bit

What steps will reproduce the problem?
(1) Create and destroy multiple BrowserContext instances at the same time.

What is the expected output?
No assertions should be hit.

What do you see instead?
Hit DCHECK(!is_worker_ref_count_disabled_) in RenderProcessHostImpl::ForceReleaseWorkerRefCounts()

Please use labels and text to provide additional information.
The problem is that:

1. RenderProcessHostImpl keeps a raw BrowserContext pointer (browser_context_) and does not clear this pointer when the BrowserContext is deleted.

2. There is an asynchronous delay between deletion of the BrowserContext and deletion of the associated RenderProcessHostImpl. This means that RenderProcessHostImpl::GetBrowserContext() may return a stale (already deleted) pointer.

3. BrowserContext::NotifyWillBeDestroyed() may call RenderProcessHostImpl::ForceReleaseWorkerRefCounts() multiple times for the same RenderProcessHostImpl instance in cases where:

A. RenderProcessHostImpl::GetBrowserContext() returns a stale (already deleted) pointer, and;

B. The pointer address has already been reused for a new BrowserContext instance.


Detailed explanation:

ProfileImpl::~ProfileImpl() calls Profile::MaybeSendDestroyedNotification() which calls BrowserContext::NotifyWillBeDestroyed(). NotifyWillBeDestroyed() uses RenderProcessHost::AllHostsIterator() to iterate existing RenderProcessHostImpl instances and compares RenderProcessHostImpl::GetBrowserContext() to the BrowserContext instance being deleted (passed to NotifyWillBeDestroyed).

This bug can be triggered by creating and destroying multiple BrowserContext instances at the same time. When an old BrowserContext instance is deleted and a new BrowserContext instance is created the old instance's pointer address might be reused for the new BrowserContext instance. When the new BrowserContext is then deleted the RenderProcessHost::AllHostsIterator() list might still contain both the old RenderProcessHostImpl instance and the new RenderProcessHostImpl instance. This results in the following situation:

1. NotifyWillBeDestroyed() will call ForceReleaseWorkerRefCounts() for the old RenderProcessHostImpl when the old BrowserContext is deleted, and;

2. NotifyWillBeDestroyed() will call ForceReleaseWorkerRefCounts() again for the old RenderProcessHostImpl when the new BrowserContext is deleted.

#1 is correct and #2 is incorrect.

This problem can be avoided by clearing the |RenderProcessHostImpl::browser_context_| pointer when the BrowserContext calls ForceReleaseWorkerRefCounts() to signal its deletion. In that case when NotifyWillBeDestroyed() is called in #2 the old RenderProcessHostImpl instance will now return nullptr instead of returning the old (already deleted) BrowserContext pointer.

Here's the fix that works for me:

diff --git a/content/browser/renderer_host/render_process_host_impl.cc b/content/browser/renderer_host/render_process_host_impl.cc
index f952adc..e9998f3 100644
--- a/content/browser/renderer_host/render_process_host_impl.cc
+++ b/content/browser/renderer_host/render_process_host_impl.cc
@@ -1395,6 +1409,7 @@ void RenderProcessHostImpl::ForceReleaseWorkerRefCounts() {
   DCHECK_CURRENTLY_ON(BrowserThread::UI);
   DCHECK(!is_worker_ref_count_disabled_);
   is_worker_ref_count_disabled_ = true;
+  browser_context_ = nullptr;
   if (!worker_ref_count())
     return;
   service_worker_ref_count_ = 0;