New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 802966 link

Starred by 7 users

Issue metadata

Status: Duplicate
Merged: issue 819678
Owner:
Closed: Apr 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 3
Type: Bug
Hotlist-MemoryInfra



Sign in to add a comment

Mac: Browser process pinned at 125% CPU for task_manager::TaskGroupSampler::RefreshMemoryUsage()

Project Member Reported by tapted@chromium.org, Jan 17 2018

Issue description

Chrome Version       : 65.0.3294.5
OS Version: OS X 10.12.6

Is this expected?

My Chrome is very unhappy. I think two threads are fighting in the browser process. I have a lot of tabs, but they're not doing much.

    2276 Thread_9681: MemoryInfra
    + 2276 thread_start  (in libsystem_pthread.dylib) + 13  [0x7fffe8cce08d]
    +   2276 _pthread_start  (in libsystem_pthread.dylib) + 286  [0x7fffe8cce887]
    +     2276 _pthread_body  (in libsystem_pthread.dylib) + 180  [0x7fffe8cce93b]
    +       2276 base::(anonymous namespace)::ThreadFunc(void*)  (in Google Chrome Framework)  load address 0x10ce12000 + 0x1e82467  [platform_thread_posix.cc:77]
    +         2276 base::Thread::ThreadMain()  (in Google Chrome Framework)  load address 0x10ce12000 + 0x1e87abb  [lock.h:26]
    +           2276 <name omitted>  (in Google Chrome Framework)  load address 0x10ce12000 + 0x1e557e5  [run_loop.cc:315]
    +             2276 base::MessagePumpCFRunLoopBase::Run(base::MessagePump::Delegate*)  (in Google Chrome Framework)  load address 0x10ce12000 + 0x1e3272e  [message_pump_mac.mm:302]
    +               2276 base::MessagePumpCFRunLoop::DoRun(base::MessagePump::Delegate*)  (in Google Chrome Framework)  load address 0x10ce12000 + 0x1e3369f  [message_pump_mac.mm:671]
    +                 2276 CFRunLoopRunSpecific  (in CoreFoundation) + 420  [0x7fffd2d6c544]
    +                   1746 __CFRunLoopRun  (in CoreFoundation) + 1361  [0x7fffd2d6ccf1]
    +                   ! 1746 __CFRunLoopServiceMachPort  (in CoreFoundation) + 212  [0x7fffd2d6d874]
    +                   !   1746 mach_msg  (in libsystem_kernel.dylib) + 55  [0x7fffe8bdb797]
    +                   !     1746 mach_msg_trap  (in libsystem_kernel.dylib) + 10  [0x7fffe8bdc34a]
    +                   530 __CFRunLoopRun  (in CoreFoundation) + 934  [0x7fffd2d6cb46]
    +                     530 __CFRunLoopDoSources0  (in CoreFoundation) + 556  [0x7fffd2d6d65c]
    +                       530 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__  (in CoreFoundation) + 17  [0x7fffd2d8c3e1]
    +                         530 base::MessagePumpCFRunLoopBase::RunWorkSource(void*)  (in Google Chrome Framework)  load address 0x10ce12000 + 0x1e32c0f  [message_pump_mac.mm:432]
    +                           530 base::mac::CallWithEHFrame(void () block_pointer)  (in Google Chrome Framework)  load address 0x10ce12000 + 0x1e24e0a  []
    +                             530 base::MessagePumpCFRunLoopBase::RunWork()  (in Google Chrome Framework)  load address 0x10ce12000 + 0x1e332ea  [message_pump_mac.mm:453]
    +                               530 base::MessageLoop::DoWork()  (in Google Chrome Framework)  load address 0x10ce12000 + 0x1e314c9  [message_loop.cc:447]
    +                                 530 base::MessageLoop::RunTask(base::PendingTask*)  (in Google Chrome Framework)  load address 0x10ce12000 + 0x1e30fc4  [vector:639]
    +                                   530 base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*)  (in Google Chrome Framework)  load address 0x10ce12000 + 0x1e0c97c  [callback_forward.h:11]
    +                                     523 base::trace_event::MemoryDumpManager::InvokeOnMemoryDump(base::trace_event::MemoryDumpManager::ProcessMemoryDumpAsyncState*)  (in Google Chrome Framework)  load address 0x10ce12000 + 0x1e946d5  [memory:2549]
    +                                     : 523 base::trace_event::MemoryDumpManager::SetupNextMemoryDump(std::__1::unique_ptr<base::trace_event::MemoryDumpManager::ProcessMemoryDumpAsyncState, std::__1::default_delete<base::trace_event::MemoryDumpManager::ProcessMemoryDumpAsyncState> >)  (in Google Chrome Framework)  load address 0x10ce12000 + 0x1e93ec6  [memory:2549]
 /* nests another ~40 stacks deep */

and

    2276 Thread_19210915: TaskSchedulerBackgroundBlockingWorker
    + 2276 thread_start  (in libsystem_pthread.dylib) + 13  [0x7fffe8cce08d]
    +   2276 _pthread_start  (in libsystem_pthread.dylib) + 286  [0x7fffe8cce887]
    +     2276 _pthread_body  (in libsystem_pthread.dylib) + 180  [0x7fffe8cce93b]
    +       2276 base::(anonymous namespace)::ThreadFunc(void*)  (in Google Chrome Framework)  load address 0x10ce12000 + 0x1e82467  [platform_thread_posix.cc:77]
    +         2275 base::internal::SchedulerWorker::Thread::ThreadMain()  (in Google Chrome Framework)  load address 0x10ce12000 + 0x1e71050  [scoped_refptr.h:203]
    +         ! 2275 base::internal::TaskTracker::RunNextTask(scoped_refptr<base::internal::Sequence>, base::internal::CanScheduleSequenceObserver*)  (in Google Chrome Framework)  load address 0x10ce12000 + 0x1e7621c  [memory:2549]
    +         !   2275 base::internal::TaskTrackerPosix::RunOrSkipTask(std::__1::unique_ptr<base::internal::Task, std::__1::default_delete<base::internal::Task> >, base::internal::Sequence*, bool)  (in Google Chrome Framework)  load address 0x10ce12000 + 0x1e7749c  [memory:2549]
    +         !     2275 base::internal::TaskTracker::RunOrSkipTask(std::__1::unique_ptr<base::internal::Task, std::__1::default_delete<base::internal::Task> >, base::internal::Sequence*, bool)  (in Google Chrome Framework)  load address 0x10ce12000 + 0x1e768e7  [task_tracker.cc:409]
    +         !       2275 base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*)  (in Google Chrome Framework)  load address 0x10ce12000 + 0x1e0c97c  [callback_forward.h:11]
    +         !         2274 base::(anonymous namespace)::PostTaskAndReplyRelay::RunTaskAndPostReply()  (in Google Chrome Framework)  load address 0x10ce12000 + 0x1e82629  [callback_forward.h:11]
    +         !         : 2273 base::internal::Invoker<base::internal::BindState<void (*)(base::OnceCallback<task_manager::MemoryUsageStats ()>, task_manager::MemoryUsageStats*), base::OnceCallback<task_manager::MemoryUsageStats ()>, task_manager::MemoryUsageStats*>, void ()>::RunOnce(base::internal::BindStateBase*)  (in Google Chrome Framework)  load address 0x10ce12000 + 0x1cc218b  [callback_forward.h:11]
    +         !         : | 2273 void base::internal::ReturnAsParamAdapter<task_manager::MemoryUsageStats>(base::OnceCallback<task_manager::MemoryUsageStats ()>, task_manager::MemoryUsageStats*)  (in Google Chrome Framework)  load address 0x10ce12000 + 0x1cc20db  [callback_forward.h:11]
    +         !         : |   2273 base::internal::Invoker<base::internal::BindState<task_manager::MemoryUsageStats (task_manager::TaskGroupSampler::*)(), scoped_refptr<task_manager::TaskGroupSampler> >, task_manager::MemoryUsageStats ()>::Run(base::internal::BindStateBase*)  (in Google Chrome Framework)  load address 0x10ce12000 + 0x1cc1f3a  [bind_internal.h:353]
    +         !         : |     2273 task_manager::TaskGroupSampler::RefreshMemoryUsage()  (in Google Chrome Framework)  load address 0x10ce12000 + 0x1cc1da3  [task_group_sampler.cc:132]
    +         !         : |       616 base::ProcessMetrics::GetMemoryBytes(unsigned long*, unsigned long*, unsigned long*, unsigned long*) const  (in Google Chrome Framework)  load address 0x10ce12000 + 0x1e50238  [process_metrics_mac.cc:489]



UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3294.5 Safari/537.36



 
worker_thread_pinned.txt
705 KB View Download
Screen Shot 2018-01-17 at 3.54.11 pm.png
233 KB View Download
Cc: -erikc...@chromium.org
Owner: erikc...@chromium.org
Status: Assigned (was: Unconfirmed)
If you remove the "Memory" column [which is now off by default], and close and reopen the task manager, the problem should go away. Now that we have Memory Footprint, I think we should remove "Memory" entirely - as the calculation is very CPU intensive - and the number is not as useful. But some other people still want the "memory column". See https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/ELSYMXnvbBc

I could change the calculation we use on macOS to be faster...and expose a slightly different inaccurate memory calculation. *shrug*. 
Cc: ellyjo...@chromium.org erikc...@chromium.org rsesek@chromium.org mark@chromium.org
 Issue 811101  has been merged into this issue.
Issue 819243 has been merged into this issue.
Issue 830305 has been merged into this issue.
Mergedinto: 819678
Status: Duplicate (was: Assigned)
This is fixed on trunk: https://bugs.chromium.org/p/chromium/issues/detail?id=819678&can=1&q=owner%3Aerikchen%40chromium.org&sort=-modified&colspec=ID%20Pri%20M%20Iteration%20ReleaseBlock%20Cr%20Status%20Owner%20Summary%20OS%20Modified

The computation for the "Memory" column was expensive and not providing utility so the column has been removed.

Sign in to add a comment