New issue
Advanced search Search tips

Issue 822082 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 3
Type: Bug



Sign in to add a comment

Renderer process hangs in cc::ProxyMain::BeginMainFrame

Project Member Reported by kbr@chromium.org, Mar 15 2018

Issue description

Chrome Version: 67.0.3366.0 (Official Build) canary (64-bit)
OS: macOS 10.13.3

What steps will reproduce the problem?
(1) Open a tab with Google Drive to a folder that contains both a Google Spreadsheet and a Microsoft Word .docx file
(2) Double-click to open the spreadsheet in another tab.
(3) Click the "Share" button on the spreadsheet to raise the dialog on that tab.
(4) Switch back to the Drive folder to open the .docx file.

What is the expected result?

Expect to be able to view the .docx file.


What happens instead?

Renderer process is hung in cc::ProxyMain::BeginMainFrame. Had to switch back to the Google Sheet and dismiss the "Share" dialog to kick things off again.

Wasn't able to reproduce. These are approximate repro steps. Tested with ~20 open tabs in the same window, and cycling through all of them. See attached output from "sample [pid] -file [file]" and fed through crsym.

There's an XMLHttpRequest being serviced by a background thread and trying to fire event listeners, but only one sample was gathered with that stack trace, and I don't think that there's a deadlock with BeginMainFrame.

Marking P3; only a bug sighting. Feel free to close as WontFix.

Call graph:
    7834 Thread_2840531   DispatchQueue_1: com.apple.main-thread  (serial)
    + 7834 start  (in libdyld.dylib) + 1  [0x7fff5b26c115]
    +   7834 main  (in Google Chrome Helper) + 1788  [chrome_exe_main_mac.cc:169]
    +     7834 ChromeMain  (in Google Chrome Framework) + 179  [chrome_main.cc:0]
    +       7834 content::ContentMain(content::ContentMainParams const&)  (in Google Chrome Framework)  load address 0x10bc08000 + 0x1c84734  [content_main.cc:19]
    +         7834 service_manager::Main(service_manager::MainParams const&)  (in Google Chrome Framework)  load address 0x10bc08000 + 0x34764d2  [main.cc:453]
    +           7834 content::ContentMainRunnerImpl::Run()  (in Google Chrome Framework)  load address 0x10bc08000 + 0x1c851e9  [content_main_runner.cc:703]
    +             7834 content::RendererMain(content::MainFunctionParams const&)  (in Google Chrome Framework)  load address 0x10bc08000 + 0x5fa6b4d  [renderer_main.cc:227]
    +               7834 <name omitted>  (in Google Chrome Framework)  load address 0x10bc08000 + 0x20b1015  [run_loop.cc:139]
    +                 7834 base::MessagePumpCFRunLoopBase::Run(base::MessagePump::Delegate*)  (in Google Chrome Framework)  load address 0x10bc08000 + 0x208c3be  [message_pump_mac.mm:311]
    +                   7834 base::MessagePumpNSRunLoop::DoRun(base::MessagePump::Delegate*)  (in Google Chrome Framework)  load address 0x10bc08000 + 0x208d5ee  [message_pump_mac.mm:734]
    +                     7834 -[NSRunLoop(NSRunLoop) runMode:beforeDate:]  (in Foundation) + 277  [0x7fff35a2ac16]
    +                       7834 CFRunLoopRunSpecific  (in CoreFoundation) + 483  [0x7fff33958f43]
    +                         7834 __CFRunLoopRun  (in CoreFoundation) + 1293  [0x7fff339596dd]
    +                           7834 __CFRunLoopDoSources0  (in CoreFoundation) + 208  [0x7fff3395a260]
    +                             7834 __CFRunLoopDoSource0  (in CoreFoundation) + 108  [0x7fff33a310ac]
    +                               7834 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__  (in CoreFoundation) + 17  [0x7fff33977721]
    +                                 7834 base::MessagePumpCFRunLoopBase::RunWorkSource(void*)  (in Google Chrome Framework)  load address 0x10bc08000 + 0x208c89f  [message_pump_mac.mm:441]
    +                                   7834 base::mac::CallWithEHFrame(void () block_pointer)  (in Google Chrome Framework)  load address 0x10bc08000 + 0x207e9ca  []
    +                                     7834 base::MessagePumpCFRunLoopBase::RunWork()  (in Google Chrome Framework)  load address 0x10bc08000 + 0x208cf93  [message_pump_mac.mm:467]
    +                                       7834 base::MessageLoop::DoDelayedWork(base::TimeTicks*)  (in Google Chrome Framework)  load address 0x10bc08000 + 0x208b106  [message_loop.cc:407]
    +                                         7834 base::MessageLoop::RunTask(base::PendingTask*)  (in Google Chrome Framework)  load address 0x10bc08000 + 0x208aae4  [vector:639]
    +                                           7834 base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*)  (in Google Chrome Framework)  load address 0x10bc08000 + 0x20660d8  [callback_forward.h:11]
    +                                             7834 blink::scheduler::internal::ThreadControllerImpl::DoWork(blink::scheduler::internal::SequencedTaskSource::WorkType)  (in Google Chrome Framework)  load address 0x10bc08000 + 0x1b643ff  [weak_ptr.h:243]
    +                                               7834 base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*)  (in Google Chrome Framework)  load address 0x10bc08000 + 0x20660d8  [callback_forward.h:11]
    +                                                 7834 void base::internal::Invoker<base::internal::BindState<void (cc::ProxyMain::*)(std::__1::unique_ptr<cc::BeginMainFrameAndCommitState, std::__1::default_delete<cc::BeginMainFrameAndCommitState> >), base::WeakPtr<cc::ProxyMain>, base::internal::PassedWrapper<std::__1::unique_ptr<cc::BeginMainFrameAndCommitState, std::__1::default_delete<cc::BeginMainFrameAndCommitState> > > >, void ()>::RunImpl<void (cc::ProxyMain::*)(std::__1::unique_ptr<cc::BeginMainFrameAndCommitState, std::__1::default_delete<cc::BeginMainFrameAndCommitState> >), std::__1::tuple<base::WeakPtr<cc::ProxyMain>, base::internal::PassedWrapper<std::__1::unique_ptr<cc::BeginMainFrameAndCommitState, std::__1::default_delete<cc::BeginMainFrameAndCommitState> > > >, 0ul, 1ul>(void (cc::ProxyMain::*&&)(std::__1::unique_ptr<cc::BeginMainFrameAndCommitState, std::__1::default_delete<cc::BeginMainFrameAndCommitState> >), std::__1::tuple<base::WeakPtr<cc::ProxyMain>, base::internal::PassedWrapper<std::__1::unique_ptr<cc::BeginMainFrameAndCommitState, std::__1::default_delete<cc::BeginMainFrameAndCommitState> > > >&&, std::__1::integer_sequence<unsigned long, 0ul, 1ul>)  (in Google Chrome Framework)  load address 0x10bc08000 + 0x2f46dfb  [memory:2643]
    +                                                   7834 cc::ProxyMain::BeginMainFrame(std::__1::unique_ptr<cc::BeginMainFrameAndCommitState, std::__1::default_delete<cc::BeginMainFrameAndCommitState> >)  (in Google Chrome Framework)  load address 0x10bc08000 + 0x2f480fa  [completion_event.h:35]
    +                                                     7834 base::WaitableEvent::Wait()  (in Google Chrome Framework)  load address 0x10bc08000 + 0x20c6cdf  [waitable_event_mac.cc:107]
    +                                                       7834 base::WaitableEvent::TimedWaitUntil(base::TimeTicks const&)  (in Google Chrome Framework)  load address 0x10bc08000 + 0x20c6db5  [waitable_event_mac.cc:149]
    +                                                         7834 mach_msg  (in libsystem_kernel.dylib) + 60  [0x7fff5b3b1cdc]
    +                                                           7834 mach_msg_trap  (in libsystem_kernel.dylib) + 10  [0x7fff5b3b27c2]

 
hung-drive-renderer.txt
90.5 KB View Download
Owner: sunn...@chromium.org
Status: Assigned (was: Untriaged)
Could be infamous BeginMainFrame hang bug, but now with a repro! I'll try and reproduce this today.

Sign in to add a comment