Chrome OS with debug on consistently crashing |
|||
Issue descriptionChrome Version : 69.0.3495.0 What steps will reproduce the problem? 1. Launch Chrome OS with debug on. 2. Open launcher and type for a period of time (varies) What is the expected result? Chrome OS does not crash. What happens instead of that? Chrome OS crashes. Please provide any additional information below. Attach a screenshot if possible. Running with debug on, on top of tree July 17 2018 (aaf227f7bd74557f983b187c50c322180f0f38a7) Stack Trace: [101550:101550:0718/153241.834703:FATAL:navigation_controller_impl.cc(999)] Check failed: !params.history_list_was_cleared. #0 0x7f1fadcb483d base::debug::StackTrace::StackTrace() #1 0x7f1fad9c93cc base::debug::StackTrace::StackTrace() #2 0x7f1fada3308d logging::LogMessage::~LogMessage() #3 0x7f1fa6a630e0 content::NavigationControllerImpl::ClassifyNavigation() #4 0x7f1fa6a6225a content::NavigationControllerImpl::RendererDidNavigate() #5 0x7f1fa6ab4c85 content::NavigatorImpl::DidNavigate() #6 0x7f1fa6ad4dc0 content::RenderFrameHostImpl::DidCommitNavigationInternal() #7 0x7f1fa6ad3f7f content::RenderFrameHostImpl::DidCommitProvisionalLoad() #8 0x7f1fa577c017 content::mojom::FrameHostStubDispatch::Accept() #9 0x7f1fa6b0b043 content::mojom::FrameHostStub<>::Accept() #10 0x7f1fabdf10e5 mojo::InterfaceEndpointClient::HandleValidatedMessage() #11 0x7f1fabdefba1 mojo::InterfaceEndpointClient::HandleIncomingMessageThunk::Accept() #12 0x7f1fabdee048 mojo::FilterChain::Accept() #13 0x7f1fabdf3a76 mojo::InterfaceEndpointClient::HandleIncomingMessage() #14 0x7f1faa7f5cf2 IPC::(anonymous namespace)::ChannelAssociatedGroupController::AcceptOnProxyThread() #15 0x7f1faa7ec4ae _ZN4base8internal13FunctorTraitsIMN3IPC12_GLOBAL__N_132ChannelAssociatedGroupControllerEFvN4mojo7MessageEEvE6InvokeIS8_RK13scoped_refptrIS4_EJS6_EEEvT_OT0_DpOT1_ #16 0x7f1faa7ec39f _ZN4base8internal12InvokeHelperILb0EvE8MakeItSoIRKMN3IPC12_GLOBAL__N_132ChannelAssociatedGroupControllerEFvN4mojo7MessageEEJRK13scoped_refptrIS6_ES8_EEEvOT_DpOT0_ #17 0x7f1faa7ec327 _ZN4base8internal7InvokerINS0_9BindStateIMN3IPC12_GLOBAL__N_132ChannelAssociatedGroupControllerEFvN4mojo7MessageEEJ13scoped_refptrIS5_ENS0_13PassedWrapperIS7_EEEEEFvvEE7RunImplIRKS9_RKNSt3__15tupleIJSB_SD_EEEJLm0ELm1EEEEvOT_OT0_NSK_16integer_sequenceImJXspT1_EEEE #18 0x7f1faa7ec21c _ZN4base8internal7InvokerINS0_9BindStateIMN3IPC12_GLOBAL__N_132ChannelAssociatedGroupControllerEFvN4mojo7MessageEEJ13scoped_refptrIS5_ENS0_13PassedWrapperIS7_EEEEEFvvEE3RunEPNS0_13BindStateBaseE #19 0x7f1fad97a97e _ZNO4base12OnceCallbackIFvvEE3RunEv #20 0x7f1fad9ca7ba base::debug::TaskAnnotator::RunTask() #21 0x7f1fada5da80 base::MessageLoop::RunTask() #22 0x7f1fada5dcc5 base::MessageLoop::DeferOrRunPendingTask() #23 0x7f1fada5dfef base::MessageLoop::DoWork() #24 0x7f1fadcf914b base::MessagePumpLibevent::Run() #25 0x7f1fada5d36e base::MessageLoop::Run() #26 0x7f1fadb055f2 base::RunLoop::Run() #27 0x558d962e34fa ChromeBrowserMainParts::MainMessageLoopRun() #28 0x7f1fa65a872a content::BrowserMainLoop::RunMainMessageLoopParts() #29 0x7f1fa65b0170 content::BrowserMainRunnerImpl::Run() #30 0x7f1fa659be10 content::BrowserMain() #31 0x7f1fa86d3a64 content::RunBrowserProcessMain() #32 0x7f1fa86d626a content::ContentMainRunnerImpl::Run() #33 0x7f1fa86caacc content::ContentServiceManagerMainDelegate::RunEmbedderProcess() #34 0x7f1fadfcac41 service_manager::Main() #35 0x7f1fa86d0c45 content::ContentMain() #36 0x558d930828f6 ChromeMain #37 0x558d93082802 main #38 0x7f1f875b42b1 __libc_start_main #39 0x558d930826da _start
,
Jul 18
,
Jul 18
It isn't anything specific. I'm developing a feature right now that uses the launcher search box and I'm just typing random queries in there. The search results in the launcher appear to be updating normally.
,
Jul 18
Some additional info that might help: This happens directly before the failed check above. [111681:111681:0718/161554.472142:ERROR:answer_card_web_contents.cc(121)] Failed to parse response headers: SearchAnswer-HasResult header != true
,
Jul 18
I thought history_list_was_cleared was for layout tests. (See also should_clear_history_list.) I'd be pretty surprised if we're seeing it on navigations in practice, especially to existing entries. Sounds like something is wrong-- can anyone else repro it?
,
Jul 18
This crash is ClassifyNavigation being called with did_create_new_entry false and history_list_was_cleared true. Those values are set in MakeDidCommitProvisionalLoadParams(). did_create_new_entry is derived on line 5456 from commit_type and other stuff. Have we messed around with MakeDidCommitProvisionalLoadParams() lately? Nate had a change that changed WebHistoryCommitType. Might it be related?
,
Jul 18
I believe my change to WebHistoryCommitType should only have affected the WebHistoryCommitType value for the first navigation in an iframe. That should map to did_create_new_entry == false both before and after, I think?
,
Jul 19
Hmmmm. Agreed. You made more things "inert" commits which would tend to make did_create_new_entry true, not false. :/ What's going on here?
,
Jul 19
I made quite a few changes to the NavigationController lately. One thing I could see is that we improperly set should_clear_history_list to true in RequestNavigationParams at the beginning of the navigation.
,
Aug 21
I can consistently repro on linux-chromeos release with dcheck on ToT @ #584811 with a clean user-data-dir. (1) Click on the launcher button (2) Type "shortcuts" (into the search field) (3) Click the Shortcuts item, wait for the window to appear (4) Repeat 1-3 (I usually hit the crash on the first time repeating step 2) Hope that helps. |
|||
►
Sign in to add a comment |
|||
Comment 1 by a...@chromium.org
, Jul 18