URLRequests show up in heap profiler even though there are no active requests |
||
Issue descriptionThe 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
,
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?
,
Jan 19 2017
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.
,
Jan 19 2017
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.
,
Jan 20 2017
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 |
||
Comment 1 by xunji...@chromium.org
, Jan 19 2017Components: Internals>Network