[5400:4748:0818/091254.094:FATAL:coordination_unit_impl.cc(89)] Check failed: it.second.
Backtrace:
	base::debug::StackTrace::StackTrace [0x01F53D20+32]
	base::debug::StackTrace::StackTrace [0x01F303BD+13]
	logging::LogMessage::~LogMessage [0x01EB817F+79]
	resource_coordinator::CoordinationUnitImpl::CreateCoordinationUnit [0x012FC902+230]
	resource_coordinator::CoordinationUnitProviderImpl::CreateCoordinationUnit [0x012FF1F7+55]
	resource_coordinator::mojom::CoordinationUnitProviderStubDispatch::Accept [0x00D2340F+223]
	resource_coordinator::mojom::CoordinationUnitProviderStub<mojo::RawPtrImplRefTraits<resource_coordinator::mojom::CoordinationUnitProvider> >::Accept [0x012FF723+19]
	mojo::InterfaceEndpointClient::HandleValidatedMessage [0x02801B85+605]

+lpy@ and fmeawad@

It looks like we create duplicate ProcessCUs.

ducbui: I'm guessing https://chromium-review.googlesource.com/c/585906 ? It might be creating a new CU rather than duplicating a messagepipe to an existing one.

Sorry, I mean https://chromium-review.googlesource.com/613820

the last reland is https://chromium-review.googlesource.com/c/617982

That may cause by multi-processes? We created it in browser process but hook it up in render process when we initialize blink platform.

The DCHECK() failed because GRC tries to create new coordination unit with duplicated ID: id.id = 0 and id.type = kProcess.

The reason is base::ProcessHandle RenderProcessHostImpl::GetHandle() return 0 (kNullProcessHandle) when (!child_process_launcher_.get() || child_process_launcher_->IsStarting()) condition is true.
https://cs.chromium.org/chromium/src/content/browser/renderer_host/render_process_host_impl.cc?sq=package:chromium&l=2778

When the DCHECK failed, there were multiple requests from BlinkResourceCoordination while GetHandle() returns the same number 0 instead of unique process handle. I observe this happens only when the machine is overloaded so child_process_launcher_ might take long time to finish.

+erikchen@

Hello Erik, I think process id is added by you as cu id in your patch? Do you have any suggestion here?

Interesting. The problem is that we make the RPH makes the CU before it has its process ID [which is being overloaded to be the CU id]. 

I think the easiest solution is to break out a separate field for PID that isn't CU id, and then the RPH can fill in that field when the handle is available.

I think we won't be allowed to have pid in GRC, since it will be accessible by render process itself.

there's no reason the field needs to be exposed to the renderer. Visiblity seems to be a general issue that GRC needs to work out.

Oystein, what do you think if we duplicate some PropertyType to something like SandboxedPropertyType that is accessible without security concern?

This prevented a patch I have out from landing: https://chromium-swarm.appspot.com/task?id=3810c40213102410&refresh=10&show_raw=1&wide_logs=true . Can we get this fixed soon? I'm randomly picking Erik as an owner (sorry).

over to oysteine, GRC owner.

As a workaround, I will return nullptr for GetProcessCU if process id is not valid, and create it later.

There's no general accessor functionality for the GRC that renderers can use to arbitrarily pull out data, so the GRC having PIDs is a non-issue. Moving it to a separate property rather than baked into the ID sgtm, though.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/19278fd88ddaf88a73d70acd4ff65392fb3531da

commit 19278fd88ddaf88a73d70acd4ff65392fb3531da
Author: Peiyong Lin <lpy@chromium.org>
Date: Tue Aug 22 18:32:03 2017

[GRC] Add PID as property to ProcessCoordinationUnit.

Instead of setting up Process Coordination Unit with a pid, this patch
sends a pid when the process is launched. A ProcessCoordinationUnit is
issued to be created from the Blink side when Blink is initialized,
however, under some conditions, the process is not yet ready, which
results in duplication ProcessCoordinationUnit with the same pid
because GetHandle returns kNullProcessHandle.

BUG= 756891 

Change-Id: I3dc79da5a3ad2a23bbec7952607634a272bbdfb7
Reviewed-on: https://chromium-review.googlesource.com/623916
Reviewed-by: Emily Stark <estark@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Oystein Eftevaag <oysteine@chromium.org>
Commit-Queue: lpy <lpy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#496379}
[modify] https://crrev.com/19278fd88ddaf88a73d70acd4ff65392fb3531da/content/browser/renderer_host/render_process_host_impl.cc
[modify] https://crrev.com/19278fd88ddaf88a73d70acd4ff65392fb3531da/services/resource_coordinator/coordination_unit/coordination_unit_introspector_impl.cc
[modify] https://crrev.com/19278fd88ddaf88a73d70acd4ff65392fb3531da/services/resource_coordinator/public/interfaces/signals.mojom

Marked as fixed.

Thanks team for the quick action here. I appreciate it!