Please note that this issue was submitted on a different computer, and that the user agent string is inaccurate in some values.

The issue still happens without -darkwake=0

Erik, I think you were looking at this sort of symptoms elsewhere, so could probably route it appropriately

We recently fixed this on top of tree:
https://chromium-review.googlesource.com/c/chromium/src/+/1165603

The fix is merged to M69 [beta], but isn't on stable channel yet.

This doesn't seem to be the same issue: chrome isn't using unreasonable amounts of memory while it's frozen. Also, the problem occurs when you open chrome after the computer has slept, regardless of whether it was open before or not. Trying chrome canary didn't fix the issue.

I recently tried this again and dtrussed chrome, and it is calling kevent() multiple times every second when it is frozen.

The same thing happens with chrome canary, even when it is freshly installed after having slept.

Please use Activity Monitor to take a sample of the process while it is unresponsive and post the results here.

Dtruss output and sample:

Deleted: Archive.zip 207 KB

Archive.zip 207 KB Download

Something odd is happening. By the sample, Chrome's browser process appears to be responsive. Main and IO threads appear unblocked and just waiting for events to appear. 

Do other operations [e.g. opening a new tab, showing the booksmarks bar [cmd + shift + b]] work? 

Deleted: symbolized_sample.txt 132 KB

symbolized_sample.txt 132 KB View Download

Maybe I should clarify: Chrome itself is responsive and I can open (but not load) new tabs, but all tabs, new ones and ones already there, get stuck on "processing request". If I wait long enough, the 'Page frozen' dialog appears. When I press cmd-q, chrome then goes completely unresponsive, and I have to force-quit it.

Can you press Cmd+Q an then take a sample while it's completely unresponsive?

Here is the dtruss output and process sample after pressing cmd+q.

Deleted: Archive.zip 22.8 KB

Archive.zip 22.8 KB Download

TaskTracker shutdown is waiting forever...

"""
    +         2563 service_manager::Main(service_manager::MainParams const&)  (in Google Chrome Framework)  load address 0x103f3c000 + 0x3599d44  [main.cc:459]
    +           2563 content::ContentMainRunnerImpl::Run()  (in Google Chrome Framework)  load address 0x103f3c000 + 0x1d47b27  [content_main_runner_impl.cc:620]
    +             2563 content::BrowserMain(content::MainFunctionParams const&, std::__1::unique_ptr<content::BrowserProcessSubThread, std::__1::default_delete<content::BrowserProcessSubThread> >)  (in Google Chrome Framework)  load address 0x103f3c000 + 0xa47a57  [memory:2321]
    +               2563 content::BrowserMainRunnerImpl::Shutdown()  (in Google Chrome Framework)  load address 0x103f3c000 + 0xa4d693  [browser_main_runner_impl.cc:226]
    +                 2563 content::BrowserMainLoop::ShutdownThreadsAndCleanUp()  (in Google Chrome Framework)  load address 0x103f3c000 + 0xa4b5c2  [trace_event.h:1106]
    +                   2563 base::internal::TaskTracker::Shutdown()  (in Google Chrome Framework)  load address 0x103f3c000 + 0x219f5ff  [task_tracker.cc:312]
    +                     2563 base::internal::TaskTracker::PerformShutdown()  (in Google Chrome Framework)  load address 0x103f3c000 + 0x219f6c1  [lock.h:26]
    +                       2563 base::WaitableEvent::Wait()  (in Google Chrome Framework)  load address 0x103f3c000 + 0x21921ff  [waitable_event_mac.cc:107]
    +                         2563 base::WaitableEvent::TimedWaitUntil(base::TimeTicks const&)  (in Google Chrome Framework)  load address 0x103f3c000 + 0x21922d5  [waitable_event_mac.cc:149]
    +                           2563 mach_msg  (in libsystem_kernel.dylib) + 209  [0x7fff641037b9]
    +                             2563 mach_msg_trap  (in libsystem_kernel.dylib) + 10  [0x7fff6410420a]
"""

It looks like for ChildProcessLauncherHelper::ForceNormalProcessTerminationSync to complete.
"""
    2563 Thread_30653: TaskSchedulerSingleThreadForegroundBlocking1
    + 2563 thread_start  (in libsystem_pthread.dylib) + 13  [0x7fff642d4bf9]
    +   2563 _pthread_start  (in libsystem_pthread.dylib) + 377  [0x7fff642d550d]
    +     2563 _pthread_body  (in libsystem_pthread.dylib) + 340  [0x7fff642d5661]
    +       2563 base::(anonymous namespace)::ThreadFunc(void*)  (in Google Chrome Framework)  load address 0x103f3c000 + 0x21e08f7  [platform_thread_posix.cc:78]
    +         2563 base::internal::SchedulerWorker::RunDedicatedWorker()  (in Google Chrome Framework)  load address 0x103f3c000 + 0x2199654  [scheduler_worker.cc:0]
    +           2563 base::internal::SchedulerWorker::RunWorker()  (in Google Chrome Framework)  load address 0x103f3c000 + 0x2199819  [type_traits:4504]
    +             2563 base::internal::TaskTracker::RunAndPopNextTask(scoped_refptr<base::internal::Sequence>, base::internal::CanScheduleSequenceObserver*)  (in Google Chrome Framework)  load address 0x103f3c000 + 0x219fd5d  [task_tracker.cc:404]
    +               2563 base::internal::TaskTrackerPosix::RunOrSkipTask(base::internal::Task, base::internal::Sequence*, bool)  (in Google Chrome Framework)  load address 0x103f3c000 + 0x21e04d3  [task_tracker_posix.cc:23]
    +                 2563 base::internal::TaskTracker::RunOrSkipTask(base::internal::Task, base::internal::Sequence*, bool)  (in Google Chrome Framework)  load address 0x103f3c000 + 0x21a048a  [trace_event.h:1106]
    +                   2563 base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*)  (in Google Chrome Framework)  load address 0x103f3c000 + 0x2136957  [callback_forward.h:11]
    +                     2563 base::internal::Invoker<base::internal::BindState<void (*)(content::internal::ChildProcessLauncherHelper::Process), content::internal::ChildProcessLauncherHelper::Process>, void ()>::RunOnce(base::internal::BindStateBase*)  (in Google Chrome Framework)  load address 0x103f3c000 + 0xa86675  [child_process_launcher_helper.h:76]
    +                       2563 content::internal::ChildProcessLauncherHelper::ForceNormalProcessTerminationSync(content::internal::ChildProcessLauncherHelper::Process)  (in Google Chrome Framework)  load address 0x103f3c000 + 0xa86eae  [child_process_launcher_helper_mac.cc:254]
    +                         2563 base::EnsureProcessTerminated(base::Process)  (in Google Chrome Framework)  load address 0x103f3c000 + 0x2174f4c  [kill_mac.cc:26]
    +                           2563 __wait4  (in libsystem_kernel.dylib) + 10  [0x7fff6410e22a]
"""

symptom or root cause? Over to ellyjones to triage further. Can someone from the Mac team look into this?

Deleted: symbolized_sample2.txt 90.1 KB

symbolized_sample2.txt 90.1 KB View Download

Weird. I wonder if a renderer or some utility process is in uninterruptible wait (U state in `ps`)? In that situation the Mac implementation of WaitForChildToDie() would block indefinitely.

Perhaps after SIGKILL we should do something other than BlockingReap(), like "try immediately, try again in a second, then dump without crashing" or somesuch?

rsesek@, any ideas / can you take a peek?

Looks like this is the spike reported in issue 878733, starting from M68, as erikchen@ pointed out on that bug.

I've recently updated macOS to 10.14 (Mojave), and this issue isn't occurring anymore.

Sounds like we can close this. Please reopen if the problem occurs again.

@groby : that sounds exactly like the recent report you were discussing with us offline

I'm not sure that's the same report - as per c#13, Chrome seems still responsive here. The report we discussed offline mentioned completely frozen Chrome. 

erikchen@, rsesek@: In case you don't have access to it yet, I have a trace of that case. Reporter just has asked me to not share publicly, so can't attach here.

I looked at the sample.

Main thread is mostly idle. IO thread is completely hosed [lots of queued IPC messages]. Confirmed that user is running with the disable-AppNap patch. So not sure what else could be causing this problem. No single type of IPC message is responsible -- there's a broad variety, but most appear related to networking? Maybe if user has a lot of renderers, they all wake up and start requesting network updates...

Can confirm user has lots of renderers :)

That's why I pinged chrisha's team about this, I thought it might be related to tab suspension/wake. Is there any chance the mechanism could somehow get convinced all tabs need to be refreshed at wake? (Also: We should probably handle large amounts of resource requests anyways)

Makes sense, this definitely falls into chrisha's domain.

Over to chrisha to triage further.

Right, there's a problem currently that we send an on-wifi-resume to all tabs at once on system resume. We should change that mechanism to be staggered following the same logic as session restore (I've seen cases where it's more efficient to restart chrome then let it resume). The specific repros where it's worse than average likely has to do with exactly what the specific web contents opened do with the notification.

What is the priority around fixing this? It's - at least for the people who contact me - pretty catastrophic. A weekend of leaving a laptop alone, and opening on Monday morning means *nothing* works. (They're trying to run top, and *fork* fails for lack of resources)

We have a Q4 OKR to categorize / classify / quantify the various IPCs that are responsible for this swapstorm in aggregate. We could try to address the one or two top talkers this Q as well (like on-wifi-resume), but we suspect it's going to be a bit before we can make a dent in this.

Launching chrome://tracing before closing the lid and saving the trace on resume (after it becomes responsive) would be useful.

 Issue 884471  has been merged into this issue.