devtools: crash when double-navigating to a slow to commit URL |
||||||
Issue descriptionSteps to repro: - Have a slow to commit URL - Open up devtools - Navigate to the URL - Before it commits, navigate to it again (i.e. ctrl-l + enter) - crash trace: #0 0x7fdd7362245e base::debug::StackTrace::StackTrace() #1 0x7fdd7364364b logging::LogMessage::~LogMessage() #2 0x7fdd70f6952c content::RenderFrameDevToolsAgentHost::AboutToNavigateRenderFrame() #3 0x7fdd70ffbe8b content::RenderFrameHostImpl::SetNavigationsSuspended() #4 0x7fdd710003e1 content::RenderFrameHostManager::OnBeforeUnloadACK() #5 0x7fdd70ff1028 content::RenderFrameHostImpl::OnBeforeUnloadACK() #6 0x7fdd70ff0aa4 _ZN3IPC8MessageTI34FrameHostMsg_BeforeUnload_ACK_MetaSt5tupleIJbN4base9TimeTicksES4_EEvE8DispatchIN7content19RenderFrameHostImplES9_vMS9_FvbRKS4_SB_EEEbPKNS_7MessageEPT_PT0_PT1_T2_ #7 0x7fdd70fedbf3 content::RenderFrameHostImpl::OnMessageReceived()
,
Jul 27 2016
Any specific URL you are using? Also, do you have --enable-browser-side-navigation?
,
Jul 27 2016
I was just using the following php:
<?php
echo date('h:i:s') . "<br>";
//sleep for 5 seconds
sleep(5);
//start again
echo date('h:i:s');
?>
This isn't using the PlzNavigate flag.
,
Jul 28 2016
Seems this can't be triaged from TE end, adding TE-NeedsFurtherTriage label to further triage.
,
Aug 8 2016
The problem here is that we expect RenderFrameDevToolsAgentHost::OnCancelPendingNavigation to be called (from the RenderFrameHostImpl::CancelPending) when user navigates while pending navigation is still in place. This does not happen. @nasko, @clamy: is this expected?
,
Aug 9 2016
Requesting Dev team for further triaging since there is no manual reproducible steps.
,
Aug 9 2016
I'll see if I can run a bisect.
,
Aug 9 2016
bisect-builds isn't working because this is only crashing on a DCHECK. Is there a way to turn DCHECK_ALWAYS_ON for that script? In any case, blackhole.webpagetest.org has the same behavior (that url never commits). That should make this easier to repro.
,
Aug 17 2016
I have to dig into this some with the debugger, but thinking through it, I don't think it is valid to think that the pending RenderFrameHost will be cancelled when creating the new navigation. Poking at the code, I can see this comment, which backs it up: // ... We will reuse the pending RFH below if it matches the destination // SiteInstance. https://cs.chromium.org/chromium/src/content/browser/frame_host/render_frame_host_manager.cc?rcl=1471375518&l=2246
,
Aug 17 2016
Good point. I confirmed that this does not repro if I try to double navigate same-site to a slow to commit URL.
,
Aug 23 2016
For the record: naive solution to skip SetPending in this case didn't work. Seems like we miss initialization in this case. if (pending_ && pending_->host() == new_host) return;
,
Aug 15 2017
This is not crashing with browser side navigation, so I am tentatively closing this. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by csharrison@chromium.org
, Jul 27 2016