Repro steps:

With a debug build of Chrome:
1) Navigate to http://csreis.github.io/tests/window-open.html
2) Click "Open about:blank window"
3) In the new tab, open DevTools and execute:
   opener.name = "asdf";
   window.open("https://www.google.com", "asdf");
4) The following DCHECK gets hit in the browser process:

[49842:49842:0719/143032:FATAL:render_frame_host_manager.cc(2470)] Check failed: opener_routing_id != MSG_ROUTING_NONE (-2 vs. -2)
#0 0x7f10502823fe base::debug::StackTrace::StackTrace()
#1 0x7f10502e99cf logging::LogMessage::~LogMessage()
#2 0x7f1049882463 content::RenderFrameHostManager::CreateOpenerProxies()
#3 0x7f1049889adc content::RenderFrameHostManager::CreateProxiesForNewRenderFrameHost()
#4 0x7f1049889a05 content::RenderFrameHostManager::CreatePendingRenderFrameHost()
#5 0x7f10498816a5 content::RenderFrameHostManager::UpdateStateForNavigate()
#6 0x7f1049880b93 content::RenderFrameHostManager::Navigate()
#7 0x7f1049844c90 content::NavigatorImpl::NavigateToEntry()
#8 0x7f1049845cb8 content::NavigatorImpl::NavigateToPendingEntry()
#9 0x7f1049820414 content::NavigationControllerImpl::NavigateToPendingEntryInternal()
#10 0x7f1049818c1c content::NavigationControllerImpl::NavigateToPendingEntry()
#11 0x7f10498191b9 content::NavigationControllerImpl::LoadEntry()
#12 0x7f104981afa4 content::NavigationControllerImpl::LoadURLWithParams()
#13 0x7f10545cb1ad (anonymous namespace)::LoadURLInContents()
#14 0x7f10545c9fce chrome::Navigate()
#15 0x7f10545a1862 Browser::OpenURLFromTab()
#16 0x7f104a09c743 content::WebContentsImpl::OpenURL()
#17 0x7f104a0a110b content::WebContentsImpl::RequestOpenURL()
#18 0x7f1049847755 content::NavigatorImpl::RequestOpenURL()
#19 0x7f10498560a3 content::RenderFrameHostImpl::OpenURL()
#20 0x7f1049850fec content::RenderFrameHostImpl::OnOpenURL()

Navigating to google.com causes a cross-process navigation even in default mode, since it's the default search provider; with --site-per-process, any other site would also work.

Note that there is an opener cycle here: second tab's opener is the first tab, and first tab's opener is set to second tab by window.open in step 3.  When navigating first tab cross-process to google.com, we create proxies for the opener chain in the google.com SiteInstance.  We correctly create the first opener proxy (for the second about:blank tab).  The next opener in the chain is processed in a second pass since it's a back link (about:blank's opener points back to google.com).  The DCHECK hits because about:blank's opener points to the actual frame being navigated, which hasn't been created yet (since we create all proxies first before the actual RenderFrame), and so we fail to find a routing ID for about:blank's opener in the google.com SiteInstance.

In release builds, the net effect is that after the google.com tab finishes loading, its window.opener is valid but window.opener.opener, which is supposed to point to itself, is null.  Not terrible, but something that we should probably fix.