Note: we need to make sure we don't regress performance much while improving coverage.
Also, please attach trace here or show the heap profiler stack trace that allocated more, so that we don't have to trace the original bug while fixing this issue. I am assuming that the actual allocated size was 90MB, when you say one order off?

The trace is at
https://drive.google.com/a/google.com/file/d/0B6ho_7_ut5e1dXVnTGx6d0ExLWs/view?usp=sharing 

It shows that net::HttpStreamFactoryImpl::RequestStreamInternal is responsible for 90737 KiB of live bytes spread across 19953 jobs. The other stack where the jobs are allocated runs out of frames, so we can only see the size of half of the jobs. Heap profiler gives us 90MB, so that means net MDP is one order off.

Just to double check. Does the 90MB include tracing overhead?

Deleted: heap1.png 168 KB

	heap1.png 168 KB View Download

The 90MB does not include tracing overhead. It is an accurate representation of memory being used.

The shown stack trace should not include any tracing overhead unless there are some TRACE_EVENT(s) in the net code.
You can increase the stack trace limit and run the experiment again to see full stack traces, since the issue is reproducible on custom builds.

This trace has a much larger stack limit. The leak is not as large [only 4k alt jobs].

https://drive.google.com/a/google.com/file/d/0B6ho_7_ut5e1NVlfWEdMeVZHRms/view?usp=sharing

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

commit 385c750bda55aeca96a2b55c30d1f56b6a816f57
Author: xunjieli <xunjieli@chromium.org>
Date: Wed Apr 05 17:24:23 2017

Remove an unused QuicStreamFactory::Job constructor

Removes an unused Job constructor and add const-ness to a few member fields.

BUG= 704953 

Review-Url: https://codereview.chromium.org/2789403002
Cr-Commit-Position: refs/heads/master@{#462130}

[modify] https://crrev.com/385c750bda55aeca96a2b55c30d1f56b6a816f57/net/quic/chromium/quic_stream_factory.cc

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

commit 48e4f10eb4784c4cf1bd09efde38a86457faece2
Author: xunjieli <xunjieli@chromium.org>
Date: Tue Apr 11 23:06:53 2017

Track STL containers in QuicStreamFactory::DumpMemoryStats

This CL includes QuicStreamFactory's STL containers in
DumpMemoryStats(). This should let us know if any of them
grows too big and causes problems.

BUG= 704953 

Review-Url: https://codereview.chromium.org/2807493002
Cr-Commit-Position: refs/heads/master@{#463821}

[modify] https://crrev.com/48e4f10eb4784c4cf1bd09efde38a86457faece2/net/BUILD.gn
[modify] https://crrev.com/48e4f10eb4784c4cf1bd09efde38a86457faece2/net/http/disk_cache_based_quic_server_info.cc
[modify] https://crrev.com/48e4f10eb4784c4cf1bd09efde38a86457faece2/net/http/disk_cache_based_quic_server_info.h
[modify] https://crrev.com/48e4f10eb4784c4cf1bd09efde38a86457faece2/net/quic/chromium/properties_based_quic_server_info.cc
[modify] https://crrev.com/48e4f10eb4784c4cf1bd09efde38a86457faece2/net/quic/chromium/properties_based_quic_server_info.h
[modify] https://crrev.com/48e4f10eb4784c4cf1bd09efde38a86457faece2/net/quic/chromium/quic_server_info.h
[modify] https://crrev.com/48e4f10eb4784c4cf1bd09efde38a86457faece2/net/quic/chromium/quic_stream_factory.cc
[modify] https://crrev.com/48e4f10eb4784c4cf1bd09efde38a86457faece2/net/quic/chromium/quic_stream_factory.h
[modify] https://crrev.com/48e4f10eb4784c4cf1bd09efde38a86457faece2/net/quic/chromium/quic_stream_factory_test.cc
[modify] https://crrev.com/48e4f10eb4784c4cf1bd09efde38a86457faece2/net/quic/core/quic_server_id.cc
[modify] https://crrev.com/48e4f10eb4784c4cf1bd09efde38a86457faece2/net/quic/core/quic_server_id.h