New issue
Advanced search Search tips

Issue 682722 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Jan 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

URLRequests show up in heap profiler even though there are no active requests

Project Member Reported by xunji...@chromium.org, Jan 19 2017

Issue description

The attached trace file has native heap profiling enabled. It shows that there are no active URLRequests in the net/ MemoryDumpProvider(obtained by querying URLRequestContext::url_request_.size()). 

However, there are ~2k allocations from net::URLRequest::Start() which are not deallocated. 

Why is it that we have no URLRequests, but the function-scoped allocations (net::URLRequest::StartJob and net::URLRequest::Start) are not deallocated?

net::URLRequest::Start() goes into HttpNetworkTransaction::Start(), which appears to be the last in the stack.

↳ƒIPC::ChannelMojo::OnMessageReceived(IPC::Message const&)	
902.6 KiB
2,096
↳ƒIPC::ChannelProxy::Context::OnMessageReceived(IPC::Message const&)	
901.9 KiB
2,091
↳ƒIPC::ChannelProxy::Context::TryFilters(IPC::Message const&)	
901.9 KiB
2,091
↳ƒIPC::MessageFilterRouter::TryFilters(IPC::Message const&)	
901.9 KiB
2,091
↳ƒcontent::BrowserMessageFilter::Internal::OnMessageReceived(IPC::Message const&)	
901.2 KiB
2,086
↳ƒcontent::ResourceDispatcherHostImpl::OnMessageReceived(IPC::Message const&, content::ResourceRequesterInfo*)	
249.2 KiB
1,415
↳ƒbool IPC::MessageT<ResourceHostMsg_RequestResource_Meta, std::tuple<int, int, content::ResourceRequest>, void>::Dispatch<content::ResourceDispatcherHostImpl, content::ResourceDispatcherHostImpl, content::ResourceRequesterInfo, void (content::ResourceDispatcherHostImpl::*)(content::ResourceRequesterInfo*, int, int, content::ResourceRequest const&)>(IPC::Message const*, content::ResourceDispatcherHostImpl*, content::ResourceDispatcherHostImpl*, content::ResourceRequesterInfo*, void (content::ResourceDispatcherHostImpl::*)(content::ResourceRequesterInfo*, int, int, content::ResourceRequest const&))	
227.1 KiB
1,317
↳ƒcontent::ResourceDispatcherHostImpl::OnRequestResource(content::ResourceRequesterInfo*, int, int, content::ResourceRequest const&)	
227.1 KiB
1,317
↳ƒcontent::ResourceDispatcherHostImpl::OnRequestResourceInternal(content::ResourceRequesterInfo*, int, int, content::ResourceRequest const&, mojo::AssociatedInterfaceRequest<content::mojom::URLLoader>, mojo::AssociatedInterfacePtr<content::mojom::URLLoaderClient>)	
226.8 KiB
1,312
↳ƒcontent::ResourceDispatcherHostImpl::BeginRequest(content::ResourceRequesterInfo*, int, content::ResourceRequest const&, base::Callback<void (content::SyncLoadResult const*), (base::internal::CopyMode)1, (base::internal::RepeatMode)1> const&, int, mojo::AssociatedInterfaceRequest<content::mojom::URLLoader>, mojo::AssociatedInterfacePtr<content::mojom::URLLoaderClient>)	
226.8 KiB
1,312
↳ƒcontent::ResourceDispatcherHostImpl::ContinuePendingBeginRequest(scoped_refptr<content::ResourceRequesterInfo>, int, content::ResourceRequest const&, base::Callback<void (content::SyncLoadResult const*), (base::internal::CopyMode)1, (base::internal::RepeatMode)1> const&, int, net::HttpRequestHeaders const&, mojo::AssociatedInterfaceRequest<content::mojom::URLLoader>, mojo::AssociatedInterfacePtr<content::mojom::URLLoaderClient>, bool, int)	
226.5 KiB
1,303
↳ƒcontent::ResourceDispatcherHostImpl::BeginRequestInternal(std::unique_ptr<net::URLRequest, std::default_delete<net::URLRequest> >, std::unique_ptr<content::ResourceHandler, std::default_delete<content::ResourceHandler> >)	
225.5 KiB
1,287
↳ƒcontent::ResourceDispatcherHostImpl::StartLoading(content::ResourceRequestInfoImpl*, std::unique_ptr<content::ResourceLoader, std::default_delete<content::ResourceLoader> >)	
225.3 KiB
1,284
↳ƒcontent::ResourceLoader::StartRequest()	
225.2 KiB
1,283
↳ƒnet::URLRequest::Start()	
177.3 KiB
993
↳ƒnet::URLRequest::StartJob(net::URLRequestJob*)	
158.9 KiB
908
↳ƒnet::URLRequestHttpJob::Start()	
158.7 KiB
904
↳ƒnet::URLRequestHttpJob::AddCookieHeaderAndStart()	
152.9 KiB
852
↳ƒnet::CookieMonster::GetCookieListWithOptionsAsync(GURL const&, net::CookieOptions const&, base::Callback<void (std::vector<net::CanonicalCookie, std::allocator<net::CanonicalCookie> > const&), (base::internal::CopyMode)1, (base::internal::RepeatMode)1> const&)	
152.9 KiB
852
↳ƒnet::CookieMonster::DoCookieTaskForURL(scoped_refptr<net::CookieMonster::CookieMonsterTask> const&, GURL const&)	
152.9 KiB
852
↳ƒnet::CookieMonster::GetCookieListWithOptionsTask::Run()	
152.9 KiB
852
↳ƒnet::URLRequestHttpJob::SetCookieHeaderAndStart(std::vector<net::CanonicalCookie, std::allocator<net::CanonicalCookie> > const&)	
152.8 KiB
850
↳ƒnet::URLRequestHttpJob::StartTransaction()	
152.8 KiB
850
↳ƒnet::URLRequestHttpJob::MaybeStartTransactionInternal(int)	
152.8 KiB
850
↳ƒnet::URLRequestHttpJob::StartTransactionInternal()	
152.8 KiB
849
↳ƒnet::HttpCache::Transaction::Start(net::HttpRequestInfo const*, base::Callback<void (int), (base::internal::CopyMode)1, (base::internal::RepeatMode)1> const&, net::NetLogWithSource const&)	
152.8 KiB
849
↳ƒnet::HttpCache::Transaction::DoLoop(int)	
152.8 KiB
849
↳ƒnet::HttpCache::Transaction::DoSendRequest()	
151.1 KiB
777
↳ƒDevToolsNetworkTransaction::Start(net::HttpRequestInfo const*, base::Callback<void (int), (base::internal::CopyMode)1, (base::internal::RepeatMode)1> const&, net::NetLogWithSource const&)	
151.1 KiB
777
↳ƒnet::HttpNetworkTransaction::Start(net::HttpRequestInfo const*, base::Callback<void (int), (base::internal::CopyMode)1, (base::internal::RepeatMode)1> const&, net::NetLogWithSource const&)	
151.1 KiB
777

 
trace_1-19.json.zip
5.0 MB Download
Cc: ssid@chromium.org mmenke@chromium.org
Components: Internals>Network

Comment 2 by ssid@chromium.org, Jan 19 2017

I am a bit confused. Why are we looking at the allocation in heap profiler, when we see the same data in the dump provider? Is it the case that we miss these http session in dump provider (not part of any url_request) and it shows up only in heap profiler?
No, we don't see the same data. 

The dump provider says that there are 0 URLRequests, while heap profiler says there are ~2k URLRequest::Start() that are not deallocated.
Sid told me about Backtrace::kMaxFrameCount which I can use to make the stack taller to show the actual allocation. 

Here's a trace with Backtrace::kMaxFrameCount set to 60.

For the second last heavy dump, there are ~4k URLRequest::Start(). It's interesting that there's no active url request. The stack seems to lead to ConnectJob. I need to figure out whether the ConnectJobs are due to idle sockets. Posting the new trace here in the meanwhile.
trace_with_increased_frame.json.zip
3.2 MB Download
Status: WontFix (was: Untriaged)
I was reading the heap profiling data wrong. The trace looks about right. I need to dig deeper and make the MDP match the heap profiler data more closely. 

Sign in to add a comment