Using the per-revision bisect providing the bisect results,
Good build: 63.0.3212.0 (Revision: 500793).
Bad build: 63.0.3213.0 (Revision: 501132).

You are probably looking for a change made after 501080 (known good), but no lat
er than 501081 (first known bad).

CHANGELOG URL:

The script might not always return single CL as suspect as some perf builds might get missing due to failure.

https://chromium.googlesource.com/chromium/src/+log/158a7a01ceb96fd019e996e3501d2fd2995bebb2..27caae83cb530daaf49f9a38793e427cdf493a65?pretty=fuller&n=100

From the CL above, assigning the issue to the concern owner 

@alexmos- Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Suspect : https://chromium.googlesource.com/chromium/src/+/27caae83cb530daaf49f9a38793e427cdf493a65

Thanks!

Adding RB Label as this is a recent Regression.
Please remove if not required.
Thank You.

Confirmed that this is due to my r501081.  During the audit, with my CL there is the following renderer crash during the second round of "Loading page & waiting for onload": 

Received signal 11 SEGV_MAPERR 000000000000
#0 0x7ffff7a87c87 base::debug::StackTrace::StackTrace()
#1 0x7ffff7a877ef base::debug::(anonymous namespace)::StackDumpSignalHandler()
#2 0x7ffff7bcc330 <unknown>
#3 0x7ffff59ee9b8 content::RenderWidget::Resize()
#4 0x7ffff5944a90 content::RenderWidgetScreenMetricsEmulator::Apply()
#5 0x7ffff59e8476 content::RenderWidget::OnEnableDeviceEmulation()
#6 0x7ffff59e825a _ZN3IPC8MessageTI34ViewMsg_EnableDeviceEmulation_MetaNSt3__15tupleIJN5blink24WebDeviceEmulationParamsEEEEvE8DispatchIN7content12RenderWidgetESA_vMSA_FvRKS5_EEEbPKNS_7MessageEPT_PT0_PT1_T2_
#7 0x7ffff59e63ee content::RenderWidget::OnMessageReceived()
#8 0x7ffff59dcaab content::RenderViewImpl::OnMessageReceived()
#9 0x7ffff6d94b15 IPC::ChannelProxy::Context::OnDispatchMessage()
#10 0x7ffff7a88756 base::debug::TaskAnnotator::RunTask()
#11 0x7ffff0abc10c blink::scheduler::TaskQueueManager::ProcessTaskFromWorkQueue()
#12 0x7ffff0aba299 blink::scheduler::TaskQueueManager::DoWork()
#13 0x7ffff7a88756 base::debug::TaskAnnotator::RunTask()
#14 0x7ffff7aae924 base::MessageLoop::RunTask()
#15 0x7ffff7aaf0b1 base::MessageLoop::DoWork()
#16 0x7ffff7ab022a base::MessagePumpDefault::Run()
#17 0x7ffff7ad6210 base::RunLoop::Run()
#18 0x7ffff59f8f94 content::RendererMain()
#19 0x7ffff5b002b2 content::RunZygote()
#20 0x7ffff5b014d1 content::ContentMainRunnerImpl::Run()
#21 0x7ffff7fa1d8d service_manager::Main()
#22 0x7ffff5b00002 content::ContentMain()
#23 0x555555a91674 ChromeMain
#24 0x7fffec95cf45 __libc_start_main
#25 0x555555a914cf <unknown>

I'm investigating.

This is caused by this code in RenderWidget::OnOrientationChange when it runs on a provisional main frame: 
  WebWidget* web_widget = GetWebWidget();
  if (web_widget && web_widget->IsWebFrameWidget()) {
    WebFrameWidget* web_frame_widget = static_cast<WebFrameWidget*>(web_widget);
    web_frame_widget->LocalRoot()->SendOrientationChangeEvent();
  }

This returns true for web_widget->IsWebFrameWidget(), but web_frame_widget->LocalRoot() is null, because it's getting it from 
  WebLocalFrameImpl* WebViewFrameWidget::LocalRoot() const {
    return web_view_->MainFrameImpl();
  } 

and MainFrameImpl() is still null for a provisional main frame.

I didn't realize that IsWebFrameWidget() returns true for main frames now, but it's unfortunate that LocalRoot() is null for provisional main frames.  +dcheng/kenrb/lfg who are the widget experts for any opinions on how to deal with this.

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

commit 0b409c439665e83096af5cbc6ae6edc0bb67467b
Author: Alex Moshchuk <alexmos@chromium.org>
Date: Wed Sep 13 02:09:00 2017

Don't try to send screen orientation change events to provisional frames

DevTools audits trigger a ViewMsg_EnableDeviceEmulation on a pending
RenderFrameHost (see EmulationHandler::UpdateDeviceEmulationState, via
RenderFrameDevToolsAgentHost::AboutToNavigateRenderFrame), which is
processed by the frame's widget (WebViewFrameWidget) before the frame
commits.  In that state, RenderWidget::OnOrientationChange crashed,
because even though IsWebFrameWidget() was true for this widget,
WebViewFrameWidget::LocalRoot() returned null, since the frame
wasn't swapped into the tree yet.  The LocalRoot() was then used
to send screen orientation change events.

It doesn't make sense to fire events on a frame that hasn't committed
and isn't in the frame tree yet, so work around this by null-checking
LocalRoot().

Bug:  764202 ,  764206 
Change-Id: I26c1c9ce938abb7b18757b88356559a30aa08fec
Reviewed-on: https://chromium-review.googlesource.com/662904
Commit-Queue: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/master@{#501517}
[modify] https://crrev.com/0b409c439665e83096af5cbc6ae6edc0bb67467b/content/browser/screen_orientation/screen_orientation_browsertest.cc
[modify] https://crrev.com/0b409c439665e83096af5cbc6ae6edc0bb67467b/content/renderer/render_widget.cc

Issue 729999 has been merged into this issue.

alexmos: I've merged issue 729999 here, because your patch will certainly fix it, but this was crashing even before your change in r501081. Do you think there could be another reason that local roots for webviews are null?

Issue 764356 has been merged into this issue.

Although my fix in r501517 stopped the crash in RenderWidget::OnOrientationChange, it's not enough to completely fix this.  The next problem I'm seeing is that the renderer crashes on
  [1:1:0912/110753.702073:FATAL:WindowProxy.cpp(105)] Check failed: global_proxy_.IsEmpty(). 

Analyzing the stack of who touched the WindowProxy before commit, I got the same stack as  issue 764519 , so marking it as a blocker for this. 

@alexmos FYI after chasing down a bug report we got over on GitHub for Lighthouse, this seems to have broader impact than audits, any navigation while emulation is enabled silently fails from the perspective of CDP.

Cannot navigate the page when Emulation.setTouchEmulationEnabled is set repro steps:

(1) Connect to Chrome over the CDP and call Emulation.setTouchEmulationEnabled
(2) Page.navigate to any data URI and wait for load
(3) Page.navigate to chrome://version

Repro script: https://gist.github.com/patrickhulce/bc75e1b1d32b7f5d735abaed2982039e

If there won't be time for a fix until 9/27 with BlinkOn and OOO, is a revert an option?

#12: Thanks for the info.  Fixing  issue 764519  should fix this, but if we can't get a fix in in the next day or two, I can revert/disable the problematic bits in my CL until I get back on 9/27 to deal with it.  I see that Dmitry might already have a fix in progress for it at https://crrev.com/c/669722, so I'm hopeful that we won't need to revert (my CL fixes a bunch of other crashes and unblocks a release).  I'll still be around (in Tokyo) until 9/21.

Dmitry landed a fix for  issue 764519  (thanks Dmitry!), which should be in Tuesday's canary.  We can verify whether this is fixed then.

I've verified that audits are now working in canary 63.0.3219.0, which includes dgozman@'s fix in r502651.