Add support to create memory allocator dump in base::DiscardableMemory

Add support to create memory allocator dump in base::DiscardableMemory

The clients that use discardable memory need to make a memory dump for
tracing. But, the client do not know if the memory is purged or not. So,
discardable manager dumps the live segments and the clients would dump
all the allocations, without the knowledge from the manager. To make the
memory dumps consistent, new api is added to the base::discardable
memory interface to create a memory allocator. this method creates dump
only if the memory is live according to the manager. Note: This still
does not mean that the memory is resident in the system, and the OS
could have purged this discardable segment. This method only helps to
make the memory dumps consistent across all systems. Also, the clients
may not keep track the size of each segment they allocate. So, this api
adds the size when creating the dump. See doc https://goo.gl/AFSTRP.

BUG=503168
Committed: https://crrev.com/3e37155aca48e63f0dcae697de6fd2b9cdf2782a
Cr-Commit-Position: refs/heads/master@{#345332}

[ssid, 2015-08-21 17:08:31]

ssid@chromium.org changed reviewers:
+ reveman@chromium.org

[ssid, 2015-08-21 17:08:31]

PTAL, Thanks.

[reveman, 2015-08-21 18:05:24]

https://codereview.chromium.org/1306243003/diff/20001/base/memory/discardable...
File base/memory/discardable_memory.h (right):

https://codereview.chromium.org/1306243003/diff/20001/base/memory/discardable...
base/memory/discardable_memory.h:68: // Returns nullptr if the memory is purged
by the allocator. Returns a new
"Returns nullptr if the memory is purged by the allocator" can you remove this
part and have it always return a dump for now.

https://codereview.chromium.org/1306243003/diff/20001/content/common/discarda...
File content/common/discardable_shared_memory_heap.cc (right):

https://codereview.chromium.org/1306243003/diff/20001/content/common/discarda...
content/common/discardable_shared_memory_heap.cc:424: if (span->shared_memory()
== nullptr)
nit: !span->shared_memory()

https://codereview.chromium.org/1306243003/diff/20001/content/common/discarda...
content/common/discardable_shared_memory_heap.cc:428: std::for_each(
can you instead do a std:::find_if for span->shared_memory() and then create the
dump here instead of adding a ScopedMemorySegment function for it? as there
should only be one match..

https://codereview.chromium.org/1306243003/diff/20001/content/common/discarda...
File content/common/discardable_shared_memory_heap_unittest.cc (right):

https://codereview.chromium.org/1306243003/diff/20001/content/common/discarda...
content/common/discardable_shared_memory_heap_unittest.cc:332:
EXPECT_TRUE(heap.CreateMemoryAllocatorDump(span.get(), "discardable/test2",
hm, do we need a test for this? I'm worried that someone will exploit this to
figure out if some memory has been purged..

https://codereview.chromium.org/1306243003/diff/20001/content/common/host_dis...
File content/common/host_discardable_shared_memory_manager.cc (right):

https://codereview.chromium.org/1306243003/diff/20001/content/common/host_dis...
content/common/host_discardable_shared_memory_manager.cc:34: size_t size,
can we use shared_memory->mapped_size() instead?

https://codereview.chromium.org/1306243003/diff/20001/content/common/host_dis...
content/common/host_discardable_shared_memory_manager.cc:72: // The memory could
have been purged by the heap, but we still create a
note: there's no heap in this case

[ssid, 2015-08-21 19:02:30]

Replies inline. Thanks.

https://codereview.chromium.org/1306243003/diff/20001/base/memory/discardable...
File base/memory/discardable_memory.h (right):

https://codereview.chromium.org/1306243003/diff/20001/base/memory/discardable...
base/memory/discardable_memory.h:68: // Returns nullptr if the memory is purged
by the allocator. Returns a new
On 2015/08/21 18:05:24, reveman wrote:
> "Returns nullptr if the memory is purged by the allocator" can you remove this
> part and have it always return a dump for now.

Yes that makes sense, I will make it dump size 0.

https://codereview.chromium.org/1306243003/diff/20001/content/common/discarda...
File content/common/discardable_shared_memory_heap.cc (right):

https://codereview.chromium.org/1306243003/diff/20001/content/common/discarda...
content/common/discardable_shared_memory_heap.cc:428: std::for_each(
On 2015/08/21 18:05:24, reveman wrote:
> can you instead do a std:::find_if for span->shared_memory() and then create
the
> dump here instead of adding a ScopedMemorySegment function for it? as there
> should only be one match..

I cannot do it because I have to match the span->shared_memory() with
ScopedMemorySegment::shared_memory_ : this is a private member and not exposed.
That is why I moved the implementation inside ScopedMemorySegment. I can either
expose the memory_segment and the id from ScopedMemorySegment, which will void
the purpose of the class, or get a callback from ScopedMemorySegment with
segment and id and create dump here. But creating there looked simpler.

https://codereview.chromium.org/1306243003/diff/20001/content/common/discarda...
File content/common/discardable_shared_memory_heap_unittest.cc (right):

https://codereview.chromium.org/1306243003/diff/20001/content/common/discarda...
content/common/discardable_shared_memory_heap_unittest.cc:332:
EXPECT_TRUE(heap.CreateMemoryAllocatorDump(span.get(), "discardable/test2",
On 2015/08/21 18:05:24, reveman wrote:
> hm, do we need a test for this? I'm worried that someone will exploit this to
> figure out if some memory has been purged..

If you feel that then I will remove the purging part of the test. But otherwise
I have no other way to tell what I added really works.

[reveman, 2015-08-22 14:21:16]

https://codereview.chromium.org/1306243003/diff/20001/content/common/discarda...
File content/common/discardable_shared_memory_heap.cc (right):

https://codereview.chromium.org/1306243003/diff/20001/content/common/discarda...
content/common/discardable_shared_memory_heap.cc:428: std::for_each(
On 2015/08/21 at 19:02:30, ssid wrote:
> On 2015/08/21 18:05:24, reveman wrote:
> > can you instead do a std:::find_if for span->shared_memory() and then create
the
> > dump here instead of adding a ScopedMemorySegment function for it? as there
> > should only be one match..
> 
> I cannot do it because I have to match the span->shared_memory() with
ScopedMemorySegment::shared_memory_ : this is a private member and not exposed.
That is why I moved the implementation inside ScopedMemorySegment. I can either
expose the memory_segment and the id from ScopedMemorySegment, which will void
the purpose of the class, or get a callback from ScopedMemorySegment with
segment and id and create dump here. But creating there looked simpler.

How about adding a "bool ScopedMemorySegment::ContainsBlock(size_t start) const"
function? and keep ScopedMemorySegment::CreateMemoryAllocatorDump but remove the
"if (shared_memory_ != span->shared_memory())" check from it?

https://codereview.chromium.org/1306243003/diff/20001/content/common/discarda...
File content/common/discardable_shared_memory_heap_unittest.cc (right):

https://codereview.chromium.org/1306243003/diff/20001/content/common/discarda...
content/common/discardable_shared_memory_heap_unittest.cc:318:
span->shared_memory()->Unlock(0, 0);
Keep in mind that there's no guarantee that memory is still present on all
platforms once you've called this. It might be purged when
CreateMemoryAllocatorDump is called below.

https://codereview.chromium.org/1306243003/diff/20001/content/common/discarda...
content/common/discardable_shared_memory_heap_unittest.cc:332:
EXPECT_TRUE(heap.CreateMemoryAllocatorDump(span.get(), "discardable/test2",
On 2015/08/21 at 19:02:30, ssid wrote:
> On 2015/08/21 18:05:24, reveman wrote:
> > hm, do we need a test for this? I'm worried that someone will exploit this
to
> > figure out if some memory has been purged..
> 
> If you feel that then I will remove the purging part of the test. But
otherwise I have no other way to tell what I added really works.

You can keep the purging part but don't rely on some specific behavior except
having it produce a valid dump just like if the memory was still persistent.

[ssid, 2015-08-22 14:50:19]

Thanks, one more concern in reply.

https://codereview.chromium.org/1306243003/diff/20001/content/common/discarda...
File content/common/discardable_shared_memory_heap.cc (right):

https://codereview.chromium.org/1306243003/diff/20001/content/common/discarda...
content/common/discardable_shared_memory_heap.cc:428: std::for_each(
On 2015/08/22 14:21:16, reveman wrote:
> On 2015/08/21 at 19:02:30, ssid wrote:
> > On 2015/08/21 18:05:24, reveman wrote:
> > > can you instead do a std:::find_if for span->shared_memory() and then
create
> the
> > > dump here instead of adding a ScopedMemorySegment function for it? as
there
> > > should only be one match..
> > 
> > I cannot do it because I have to match the span->shared_memory() with
> ScopedMemorySegment::shared_memory_ : this is a private member and not
exposed.
> That is why I moved the implementation inside ScopedMemorySegment. I can
either
> expose the memory_segment and the id from ScopedMemorySegment, which will void
> the purpose of the class, or get a callback from ScopedMemorySegment with
> segment and id and create dump here. But creating there looked simpler.
> 
> How about adding a "bool ScopedMemorySegment::ContainsBlock(size_t start)
const"
> function? and keep ScopedMemorySegment::CreateMemoryAllocatorDump but remove
the
> "if (shared_memory_ != span->shared_memory())" check from it?

Yes I planned that at first, but I also need to add a subAllocation to the
segment, for which i need the segment id. That is why i moved the implementation
in there. If you want it to be implemented outside then I would have to make a
callback into the heap with id, if segment matches.

https://codereview.chromium.org/1306243003/diff/20001/content/common/discarda...
File content/common/discardable_shared_memory_heap_unittest.cc (right):

https://codereview.chromium.org/1306243003/diff/20001/content/common/discarda...
content/common/discardable_shared_memory_heap_unittest.cc:318:
span->shared_memory()->Unlock(0, 0);
On 2015/08/22 14:21:16, reveman wrote:
> Keep in mind that there's no guarantee that memory is still present on all
> platforms once you've called this. It might be purged when
> CreateMemoryAllocatorDump is called below.

Ah, yes. I will move this after create dump, I did not think of that.

[reveman, 2015-08-22 15:04:07]

https://codereview.chromium.org/1306243003/diff/20001/content/common/discarda...
File content/common/discardable_shared_memory_heap.cc (right):

https://codereview.chromium.org/1306243003/diff/20001/content/common/discarda...
content/common/discardable_shared_memory_heap.cc:428: std::for_each(
On 2015/08/22 at 14:50:19, ssid wrote:
> On 2015/08/22 14:21:16, reveman wrote:
> > On 2015/08/21 at 19:02:30, ssid wrote:
> > > On 2015/08/21 18:05:24, reveman wrote:
> > > > can you instead do a std:::find_if for span->shared_memory() and then
create
> > the
> > > > dump here instead of adding a ScopedMemorySegment function for it? as
there
> > > > should only be one match..
> > > 
> > > I cannot do it because I have to match the span->shared_memory() with
> > ScopedMemorySegment::shared_memory_ : this is a private member and not
exposed.
> > That is why I moved the implementation inside ScopedMemorySegment. I can
either
> > expose the memory_segment and the id from ScopedMemorySegment, which will
void
> > the purpose of the class, or get a callback from ScopedMemorySegment with
> > segment and id and create dump here. But creating there looked simpler.
> > 
> > How about adding a "bool ScopedMemorySegment::ContainsBlock(size_t start)
const"
> > function? and keep ScopedMemorySegment::CreateMemoryAllocatorDump but remove
the
> > "if (shared_memory_ != span->shared_memory())" check from it?
> 
> Yes I planned that at first, but I also need to add a subAllocation to the
segment, for which i need the segment id. That is why i moved the implementation
in there. If you want it to be implemented outside then I would have to make a
callback into the heap with id, if segment matches.

I was thinking you could use the ScopedMemorySegment::ContainsBlock to find the
correct segment and then use a ScopedMemorySegment::CreateMemoryAllocatorDump
function to create the dump. That function would have access to the id..

[ssid, 2015-08-22 15:13:00]

https://codereview.chromium.org/1306243003/diff/20001/content/common/discarda...
File content/common/discardable_shared_memory_heap.cc (right):

https://codereview.chromium.org/1306243003/diff/20001/content/common/discarda...
content/common/discardable_shared_memory_heap.cc:428: std::for_each(
On 2015/08/22 15:04:07, reveman wrote:
> On 2015/08/22 at 14:50:19, ssid wrote:
> > On 2015/08/22 14:21:16, reveman wrote:
> > > On 2015/08/21 at 19:02:30, ssid wrote:
> > > > On 2015/08/21 18:05:24, reveman wrote:
> > > > > can you instead do a std:::find_if for span->shared_memory() and then
> create
> > > the
> > > > > dump here instead of adding a ScopedMemorySegment function for it? as
> there
> > > > > should only be one match..
> > > > 
> > > > I cannot do it because I have to match the span->shared_memory() with
> > > ScopedMemorySegment::shared_memory_ : this is a private member and not
> exposed.
> > > That is why I moved the implementation inside ScopedMemorySegment. I can
> either
> > > expose the memory_segment and the id from ScopedMemorySegment, which will
> void
> > > the purpose of the class, or get a callback from ScopedMemorySegment with
> > > segment and id and create dump here. But creating there looked simpler.
> > > 
> > > How about adding a "bool ScopedMemorySegment::ContainsBlock(size_t start)
> const"
> > > function? and keep ScopedMemorySegment::CreateMemoryAllocatorDump but
remove
> the
> > > "if (shared_memory_ != span->shared_memory())" check from it?
> > 
> > Yes I planned that at first, but I also need to add a subAllocation to the
> segment, for which i need the segment id. That is why i moved the
implementation
> in there. If you want it to be implemented outside then I would have to make a
> callback into the heap with id, if segment matches.
> 
> I was thinking you could use the ScopedMemorySegment::ContainsBlock to find
the
> correct segment and then use a ScopedMemorySegment::CreateMemoryAllocatorDump
> function to create the dump. That function would have access to the id..

Ah sorry, I see what you meant now, sounds good, thanks

[ssid, 2015-08-24 14:52:10]

Thanks, PTAL.

https://codereview.chromium.org/1306243003/diff/20001/base/memory/discardable...
File base/memory/discardable_memory.h (right):

https://codereview.chromium.org/1306243003/diff/20001/base/memory/discardable...
base/memory/discardable_memory.h:68: // Returns nullptr if the memory is purged
by the allocator. Returns a new
On 2015/08/21 19:02:30, ssid wrote:
> On 2015/08/21 18:05:24, reveman wrote:
> > "Returns nullptr if the memory is purged by the allocator" can you remove
this
> > part and have it always return a dump for now.
> 
> Yes that makes sense, I will make it dump size 0.

Done.

https://codereview.chromium.org/1306243003/diff/20001/content/common/discarda...
File content/common/discardable_shared_memory_heap.cc (right):

https://codereview.chromium.org/1306243003/diff/20001/content/common/discarda...
content/common/discardable_shared_memory_heap.cc:424: if (span->shared_memory()
== nullptr)
On 2015/08/21 18:05:24, reveman wrote:
> nit: !span->shared_memory()

Done.

https://codereview.chromium.org/1306243003/diff/20001/content/common/discarda...
content/common/discardable_shared_memory_heap.cc:428: std::for_each(
On 2015/08/22 15:13:00, ssid wrote:
> On 2015/08/22 15:04:07, reveman wrote:
> > On 2015/08/22 at 14:50:19, ssid wrote:
> > > On 2015/08/22 14:21:16, reveman wrote:
> > > > On 2015/08/21 at 19:02:30, ssid wrote:
> > > > > On 2015/08/21 18:05:24, reveman wrote:
> > > > > > can you instead do a std:::find_if for span->shared_memory() and
then
> > create
> > > > the
> > > > > > dump here instead of adding a ScopedMemorySegment function for it?
as
> > there
> > > > > > should only be one match..
> > > > > 
> > > > > I cannot do it because I have to match the span->shared_memory() with
> > > > ScopedMemorySegment::shared_memory_ : this is a private member and not
> > exposed.
> > > > That is why I moved the implementation inside ScopedMemorySegment. I can
> > either
> > > > expose the memory_segment and the id from ScopedMemorySegment, which
will
> > void
> > > > the purpose of the class, or get a callback from ScopedMemorySegment
with
> > > > segment and id and create dump here. But creating there looked simpler.
> > > > 
> > > > How about adding a "bool ScopedMemorySegment::ContainsBlock(size_t
start)
> > const"
> > > > function? and keep ScopedMemorySegment::CreateMemoryAllocatorDump but
> remove
> > the
> > > > "if (shared_memory_ != span->shared_memory())" check from it?
> > > 
> > > Yes I planned that at first, but I also need to add a subAllocation to the
> > segment, for which i need the segment id. That is why i moved the
> implementation
> > in there. If you want it to be implemented outside then I would have to make
a
> > callback into the heap with id, if segment matches.
> > 
> > I was thinking you could use the ScopedMemorySegment::ContainsBlock to find
> the
> > correct segment and then use a
ScopedMemorySegment::CreateMemoryAllocatorDump
> > function to create the dump. That function would have access to the id..
> 
> Ah sorry, I see what you meant now, sounds good, thanks

Done.

https://codereview.chromium.org/1306243003/diff/20001/content/common/discarda...
File content/common/discardable_shared_memory_heap_unittest.cc (right):

https://codereview.chromium.org/1306243003/diff/20001/content/common/discarda...
content/common/discardable_shared_memory_heap_unittest.cc:318:
span->shared_memory()->Unlock(0, 0);
On 2015/08/22 14:21:16, reveman wrote:
> Keep in mind that there's no guarantee that memory is still present on all
> platforms once you've called this. It might be purged when
> CreateMemoryAllocatorDump is called below.

Done.

https://codereview.chromium.org/1306243003/diff/20001/content/common/discarda...
content/common/discardable_shared_memory_heap_unittest.cc:332:
EXPECT_TRUE(heap.CreateMemoryAllocatorDump(span.get(), "discardable/test2",
On 2015/08/22 14:21:16, reveman wrote:
> On 2015/08/21 at 19:02:30, ssid wrote:
> > On 2015/08/21 18:05:24, reveman wrote:
> > > hm, do we need a test for this? I'm worried that someone will exploit this
> to
> > > figure out if some memory has been purged..
> > 
> > If you feel that then I will remove the purging part of the test. But
> otherwise I have no other way to tell what I added really works.
> 
> You can keep the purging part but don't rely on some specific behavior except
> having it produce a valid dump just like if the memory was still persistent.

Done.

https://codereview.chromium.org/1306243003/diff/20001/content/common/host_dis...
File content/common/host_discardable_shared_memory_manager.cc (right):

https://codereview.chromium.org/1306243003/diff/20001/content/common/host_dis...
content/common/host_discardable_shared_memory_manager.cc:34: size_t size,
On 2015/08/21 18:05:24, reveman wrote:
> can we use shared_memory->mapped_size() instead?

Done.

https://codereview.chromium.org/1306243003/diff/20001/content/common/host_dis...
content/common/host_discardable_shared_memory_manager.cc:72: // The memory could
have been purged by the heap, but we still create a
On 2015/08/21 18:05:24, reveman wrote:
> note: there's no heap in this case

Done.

[reveman, 2015-08-24 16:50:06]

https://codereview.chromium.org/1306243003/diff/40001/content/common/discarda...
File content/common/discardable_shared_memory_heap.cc (right):

https://codereview.chromium.org/1306243003/diff/40001/content/common/discarda...
content/common/discardable_shared_memory_heap.cc:436: std::for_each(
can you use find_if instead? I think that represents the intent better and is
easier to understand.

https://codereview.chromium.org/1306243003/diff/40001/content/common/discarda...
content/common/discardable_shared_memory_heap.cc:444: DCHECK(allocator_dump !=
nullptr);
nit: DCHECK(!allocator_dump)

though this doesn't work right now as allocator_dump is not initialized to null.

https://codereview.chromium.org/1306243003/diff/40001/content/common/discarda...
File content/common/discardable_shared_memory_heap_unittest.cc (right):

https://codereview.chromium.org/1306243003/diff/40001/content/common/discarda...
content/common/discardable_shared_memory_heap_unittest.cc:321: pmd.get()) !=
nullptr);
nit: remove " != nullptr"

https://codereview.chromium.org/1306243003/diff/40001/content/common/discarda...
content/common/discardable_shared_memory_heap_unittest.cc:331: pmd.get()) !=
nullptr);
nit: remove " != nullptr"

https://codereview.chromium.org/1306243003/diff/40001/content/common/host_dis...
File content/common/host_discardable_shared_memory_manager.cc (right):

https://codereview.chromium.org/1306243003/diff/40001/content/common/host_dis...
content/common/host_discardable_shared_memory_manager.cc:82: size_t size_;
is this needed?

[ssid, 2015-08-24 17:20:43]

Patchset #5 (id:80001) has been deleted

[ssid, 2015-08-24 17:21:13]

Thanks made changes.

https://codereview.chromium.org/1306243003/diff/40001/content/common/discarda...
File content/common/discardable_shared_memory_heap.cc (right):

https://codereview.chromium.org/1306243003/diff/40001/content/common/discarda...
content/common/discardable_shared_memory_heap.cc:436: std::for_each(
On 2015/08/24 16:50:06, reveman wrote:
> can you use find_if instead? I think that represents the intent better and is
> easier to understand.

Done.

https://codereview.chromium.org/1306243003/diff/40001/content/common/discarda...
content/common/discardable_shared_memory_heap.cc:444: DCHECK(allocator_dump !=
nullptr);
On 2015/08/24 16:50:06, reveman wrote:
> nit: DCHECK(!allocator_dump)
> 
> though this doesn't work right now as allocator_dump is not initialized to
null.

Done.

https://codereview.chromium.org/1306243003/diff/40001/content/common/discarda...
File content/common/discardable_shared_memory_heap_unittest.cc (right):

https://codereview.chromium.org/1306243003/diff/40001/content/common/discarda...
content/common/discardable_shared_memory_heap_unittest.cc:321: pmd.get()) !=
nullptr);
On 2015/08/24 16:50:06, reveman wrote:
> nit: remove " != nullptr"

Done.

[reveman, 2015-08-24 17:29:02]

lgtm

[ssid, 2015-08-24 17:32:01]

ssid@chromium.org changed reviewers:
+ avi@chromium.org, thakis@chromium.org

[ssid, 2015-08-24 17:32:01]

+thakis for in base/memory

+avi for content/

Thanks.

[Nico, 2015-08-24 17:36:29]

base/ lgtm

[Avi (use Gerrit), 2015-08-24 17:43:44]

lgtm

With nit.

https://codereview.chromium.org/1306243003/diff/100001/base/memory/discardabl...
File base/memory/discardable_memory.h (right):

https://codereview.chromium.org/1306243003/diff/100001/base/memory/discardabl...
base/memory/discardable_memory.h:13: namespace trace_event {
newline before this one

https://codereview.chromium.org/1306243003/diff/100001/base/memory/discardabl...
base/memory/discardable_memory.h:68: // Returns a new MemoryAllocatorDump in the
|pmd| with the size of the
"returns a new dump" implies ownership transfer, when AFAICT this doesn't do so
(all MemoryAllocatorDumps are owned by a ProcessMemoryDump). Can you tweak the
comment to make it clear that this isn't an ownership transfer?

[ssid, 2015-08-24 17:53:55]

Thanks.

https://codereview.chromium.org/1306243003/diff/100001/base/memory/discardabl...
File base/memory/discardable_memory.h (right):

https://codereview.chromium.org/1306243003/diff/100001/base/memory/discardabl...
base/memory/discardable_memory.h:13: namespace trace_event {
On 2015/08/24 17:43:43, Avi wrote:
> newline before this one

But, most files do not seem to have the new line here.

https://codereview.chromium.org/1306243003/diff/100001/base/memory/discardabl...
base/memory/discardable_memory.h:68: // Returns a new MemoryAllocatorDump in the
|pmd| with the size of the
On 2015/08/24 17:43:43, Avi wrote:
> "returns a new dump" implies ownership transfer, when AFAICT this doesn't do
so
> (all MemoryAllocatorDumps are owned by a ProcessMemoryDump). Can you tweak the
> comment to make it clear that this isn't an ownership transfer?

Done.

[ssid, 2015-08-24 19:35:36]

ssid@chromium.org changed reviewers:
+ hendrikw@chromium.org

[ssid, 2015-08-24 19:35:36]

+hendrikw for skia_runner/

PTAL. Thanks

[hendrikw, 2015-08-24 22:00:31]

On 2015/08/24 19:35:36, ssid wrote:
> +hendrikw for skia_runner/
> 
> PTAL. Thanks

LGTM

[ssid, 2015-08-24 22:06:35]

ssid@chromium.org changed reviewers:
+ jam@chromium.org

[ssid, 2015-08-24 22:06:35]

+jam for html_viewer/. PTAL, Thanks.

[jam, 2015-08-25 15:27:18]

lgtm

[ssid, 2015-08-25 15:27:51]

The CQ bit was checked by ssid@chromium.org

[ssid, 2015-08-25 15:27:52]

The patchset sent to the CQ was uploaded after l-g-t-m from avi@chromium.org,
thakis@chromium.org, reveman@chromium.org
Link to the patchset: https://codereview.chromium.org/1306243003/#ps180001
(title: "Fix html_viewer.")

[commit-bot: I haz the power, 2015-08-25 15:27:58]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1306243003/180001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1306243003/180001

[commit-bot: I haz the power, 2015-08-25 15:33:25]

Committed patchset #9 (id:180001)

[commit-bot: I haz the power, 2015-08-25 15:35:02]

Patchset 9 (id:??) landed as
https://crrev.com/3e37155aca48e63f0dcae697de6fd2b9cdf2782a
Cr-Commit-Position: refs/heads/master@{#345332}