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

Issue 808725 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 798025
Owner:
Closed: Feb 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

NetworkQualityObserver leaks / allocates lot of mojo handles

Project Member Reported by ssid@chromium.org, Feb 3 2018

Issue description

Found quite a few reports from users with large memory usage from NetworkQualityObserverImpl tasks on Android and desktop. The large ones were 40MB on Android and crash/7347ce5121605438#6 and 160MB on Windows crash/27fe06b49dd8bff538%27#6
The Android browser and renderer were alive for 3 days before the trace was taken. I guess a lot of times the network was changed and the observer sends mojo messages.
I am not sure if this is a leak or we just use so many handles
 

Comment 1 by ssid@chromium.org, Feb 3 2018

Note: The Android trace had only one renderer process alive.
The Windows trace had browser alive for 10 days, with multiple renderers.

The stack trace of allocation on Windows:

_aligned_offset_malloc_base
_aligned_malloc_base
base::AlignedAlloc(unsigned int,unsigned int)
mojo::edk::Channel::Message::Message(unsigned int,unsigned int,unsigned int,mojo::edk::Channel::Message::MessageType)
mojo::edk::Channel::Message::Message(unsigned int,unsigned int,unsigned int)
mojo::edk::`anonymous namespace'::CreateMessage<void>
mojo::edk::NodeChannel::CreateEventMessage(unsigned int,unsigned int,void * *,unsigned int)
mojo::edk::`anonymous namespace'::CreateOrExtendSerializedEventMessage
mojo::edk::UserMessageImpl::AttachSerializedMessageBuffer(unsigned int,unsigned int const *,unsigned int)
mojo::edk::Core::AttachSerializedMessageBuffer(unsigned int,unsigned int,unsigned int const *,unsigned int,void * *,unsigned int *)
MojoAttachSerializedMessageBufferImpl
mojo::`anonymous namespace'::CreateSerializedMessageObject
mojo::Message::Message(unsigned int,unsigned int,unsigned int,unsigned int,std::vector<mojo::ScopedHandleBase<mojo::Handle>,std::allocator<mojo::ScopedHandleBase<mojo::Handle> > > *)
content::mojom::RendererProxy::OnNetworkQualityChanged(net::EffectiveConnectionType,base::TimeDelta,base::TimeDelta,double)
content::NetworkQualityObserverImpl::UiThreadObserver::OnRTTOrThroughputEstimatesComputed(net::nqe::internal::NetworkQuality const &)
base::internal::Invoker<base::internal::BindState<void (content::NetworkQualityObserverImpl::UiThreadObserver::*)(const net::nqe::internal::NetworkQuality &) __attribute__((thiscall)),base::internal::UnretainedWrapper<content::NetworkQualityObserverImpl::UiThreadObserver>,net::nqe::internal::NetworkQuality>,void ()>::RunOnce
base::debug::TaskAnnotator::RunTask(char const *,base::PendingTask *)
base::internal::IncomingTaskQueue::RunTask(base::PendingTask *)
base::MessageLoop::RunTask(base::PendingTask *)
base::MessageLoop::DeferOrRunPendingTask(base::PendingTask)
base::MessageLoop::DoWork()
base::MessagePumpForUI::DoRunLoop()
base::MessagePumpWin::Run(base::MessagePump::Delegate *)
base::MessageLoop::Run(bool)
base::RunLoop::Run()
ChromeBrowserMainParts::MainMessageLoopRun(int *)
content::BrowserMainLoop::RunMainMessageLoopParts()
content::BrowserMainRunnerImpl::Run()
content::BrowserMain(content::MainFunctionParams const &)
content::RunNamedProcessTypeMain(std::basic_string<char,std::char_traits<char>,std::allocator<char> > const &,content::MainFunctionParams const &,content::ContentMainDelegate *)
content::ContentMainRunnerImpl::Run()
service_manager::Main(service_manager::MainParams const &)
content::ContentMain(content::ContentMainParams const &)
ChromeMain
MainDllLoader::Launch(HINSTANCE__ *,base::TimeTicks)
wWinMain


I tried to enable / disable wifi lot of times and load a bunch of pages at the same time. The maximum memory allocation I could get was 1.5MB allocated by stack trace. But, the memory is cleared on closing tabs.

content::mojom::RendererProxy::OnNetworkQualityChanged(net::EffectiveConnectionType, base::TimeDelta, base::TimeDelta, double)
mojo::Message::Message(unsigned int, unsigned int, unsigned int, unsigned int, std::__ndk1::vector<mojo::ScopedHandleBase<mojo::Handle>, std::__ndk1::allocator<mojo::ScopedHandleBase<mojo::Handle> > >*)
MojoAttachSerializedMessageBufferImpl
mojo::edk::Core::AttachSerializedMessageBuffer(unsigned int, unsigned int, unsigned int const*, unsigned int, void**, unsigned int*)
mojo::edk::UserMessageImpl::AttachSerializedMessageBuffer(unsigned int, unsigned int const*, unsigned int)
mojo::edk::(anonymous namespace)::CreateOrExtendSerializedEventMessage(mojo::edk::ports::UserMessageEvent*, unsigned int, unsigned int, mojo::edk::Dispatcher::DispatcherInTransit const*, unsigned int, std::__ndk1::unique_ptr<mojo::edk::Channel::Message, std::__ndk1::default_delete<mojo::edk::Channel::Message> >*, void**, unsigned int*, void**)
mojo::edk::NodeChannel::CreateEventMessage(unsigned int, unsigned int, void**, unsigned int)
std::__ndk1::unique_ptr<mojo::edk::Channel::Message, std::__ndk1::default_delete<mojo::edk::Channel::Message> > mojo::edk::(anonymous namespace)::CreateMessage<void>(mojo::edk::(anonymous namespace)::MessageType, unsigned int, unsigned int, void**, unsigned int)
mojo::edk::Channel::Message::Message(unsigned int, unsigned int, unsigned int)
mojo::edk::Channel::Message::Message(unsigned int, unsigned int, unsigned int, mojo::edk::Channel::Message::MessageType)
base::AlignedAlloc(unsigned int, unsigned int)

Comment 2 by ssid@chromium.org, Feb 3 2018

Cc: roc...@chromium.org etienneb@chromium.org

Comment 3 by ssid@chromium.org, Feb 3 2018

Owner: tbansal@chromium.org
Assigning to owner of nqe for now.
This seems very similar to  Issue 798025 .

Comment 5 by ssid@chromium.org, Feb 3 2018

Mergedinto: 798025
Status: Duplicate (was: Untriaged)
Yeah I should have looked harder.
Project Member

Comment 6 by bugdroid1@chromium.org, Feb 6 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3e7284bb4e047557f5fc2b39164a4c9495be2bd5

commit 3e7284bb4e047557f5fc2b39164a4c9495be2bd5
Author: Ken Rockot <rockot@chromium.org>
Date: Tue Feb 06 16:11:16 2018

Ensure that queued IPC messages can't leak

Assuming based on a small amount of evidence that there may be a bug
causing some ChannelAssociatedGroupController instances to leak, this CL
ensures that in such cases, the object's outgoing message queue will not
also leak.

Bug:  808725 
Change-Id: I256dd264b811f9ccb8e8e3ee86f2b58f916f1560
Reviewed-on: https://chromium-review.googlesource.com/902813
Reviewed-by: Yuzhu Shen <yzshen@chromium.org>
Commit-Queue: Ken Rockot <rockot@chromium.org>
Cr-Commit-Position: refs/heads/master@{#534693}
[modify] https://crrev.com/3e7284bb4e047557f5fc2b39164a4c9495be2bd5/ipc/ipc_mojo_bootstrap.cc

Sign in to add a comment