In Windows 7 the tab process hangs, here's the bisect info: 475142 (good) - 475150 (bad)
https://chromium.googlesource.com/chromium/src/+log/1cf6fdc6..ee16a4e7?pretty=fuller
Suspecting r475145 "cc: Give non-drawing layers that are rasterized a lower priority"
Landed in 61.0.3113.0

Able to reproduce this issue on reported version 61.0.3163.100 and latest dev 63.0.3236.0 using Mac 10.12.6, Ubuntu 14.04 and Win 7
As per the given bisect in comment#1, suspecting https://codereview.chromium.org/2899403003

@khushalsagar: Please confirm the bug and help in re-assigning if it is not related to your change.

Since M-62 will be promoted to stable pretty soon, hence updating the blocker and milestone label accordingly for tracking.

Is there a crash id to get a stacktrace from? This sounds more likely a problem  in blink than in compositing.

Attached a trace. It looks like the compositor thread finishes LTHI::BeginCommit() but then hangs somewhere after, probably inside LayerTreeHost::FinishCommitOnImplThread()

Deleted: trace_bug.html.json.gz 784 KB

trace_bug.html.json.gz 784 KB Download

Its this part of that change https://codereview.chromium.org/2899403003/diff/160001/cc/trees/layer_tree_impl.cc. We are updating tile priorities for all layers which are going to be rasterized now, instead of just the ones we'll draw. The reason I did that was to make sure that all layers which affect tile priorities have updated info.

And as it turns out the raster_even_if_not_drawn layers are the ones which have non-invertible transforms but we still want to raster them because its animated.

Callstack while the tab hangs at 100% CPU:

>	chrome_child.dll!std::_Hash<class std::_Umap_traits<struct cc::TileMapKey,class std::unique_ptr<class cc::Tile,struct std::default_delete<class cc::Tile> >,class std::_Uhash_compare<struct cc::TileMapKey,struct cc::TileMapKeyHash,struct std::equal_to<struct cc::TileMapKey> >,class std::allocator<struct std::pair<struct cc::TileMapKey const ,class std::unique_ptr<class cc::Tile,struct std::default_delete<class cc::Tile> > > >,0> >::_Insert<struct std::pair<struct cc::TileMapKey const ,class std::unique_ptr<class cc::Tile,struct std::default_delete<class cc::Tile> > > &,class std::_List_unchecked_iterator<class std::_List_val<struct std::_List_simple_types<struct std::pair<struct cc::TileMapKey const ,class std::unique_ptr<class cc::Tile,struct std::default_delete<class cc::Tile> > > > > > >(struct std::pair<struct cc::TileMapKey const ,class std::unique_ptr<class cc::Tile,struct std::default_delete<class cc::Tile> > > &,class std::_List_unchecked_iterator<class std::_List_val<struct std::_List_simple_types<struct std::pair<st	C++
 	chrome_child.dll!cc::PictureLayerTiling::CreateTile(class cc::Tile::CreateInfo const &)	C++
 	chrome_child.dll!cc::PictureLayerTiling::SetLiveTilesRect(class gfx::Rect const &)	C++
 	chrome_child.dll!cc::PictureLayerTiling::ComputeTilePriorityRects(class gfx::Rect const &,class gfx::Rect const &,class gfx::Rect const &,class gfx::Rect const &,float,class cc::Occlusion const &)	C++
 	chrome_child.dll!cc::PictureLayerTilingSet::UpdateTilePriorities(class gfx::Rect const &,float,double,class cc::Occlusion const &,bool)	C++
 	chrome_child.dll!cc::PictureLayerImpl::UpdateTiles(void)	C++
 	chrome_child.dll!cc::LayerTreeImpl::UpdateDrawProperties(void)	C++
 	chrome_child.dll!cc::LayerTreeHostImpl::UpdateSyncTreeAfterCommitOrImplSideInvalidation(void)	C++
 	chrome_child.dll!cc::LayerTreeHostImpl::CommitComplete(void)	C++
 	chrome_child.dll!cc::ProxyImpl::ScheduledActionCommit(void)	C++
 	chrome_child.dll!cc::Scheduler::ProcessScheduledActions(void)	C++
 	chrome_child.dll!cc::Scheduler::NotifyReadyToCommit(void)	C++
 	chrome_child.dll!cc::ProxyImpl::NotifyReadyToCommitOnImpl(class cc::CompletionEvent *,class cc::LayerTreeHost *,class base::TimeTicks,bool)	C++
 	chrome_child.dll!base::internal::Invoker<struct base::internal::BindState<void ( cc::ProxyImpl::*)(class cc::CompletionEvent *,class cc::LayerTreeHost *,class base::TimeTicks,bool),class base::internal::UnretainedWrapper<class cc::ProxyImpl>,class cc::CompletionEvent *,class cc::LayerTreeHost *,class base::TimeTicks,bool>,void >::RunOnce(class base::internal::BindStateBase *)	C++
 	chrome_child.dll!base::debug::TaskAnnotator::RunTask(char const *,struct base::PendingTask *)	C++
 	chrome_child.dll!blink::scheduler::TaskQueueManager::ProcessTaskFromWorkQueue(class blink::scheduler::internal::WorkQueue *,bool,class blink::scheduler::LazyNow,class base::TimeTicks *)	C++
 	chrome_child.dll!blink::scheduler::TaskQueueManager::DoWork(bool)	C++
 	chrome_child.dll!base::internal::FunctorTraits<void ( media::AudioRendererImpl::*)(bool),void>::Invoke<class base::WeakPtr<class media::AudioRendererImpl> const &,bool>(void ( media::AudioRendererImpl::*)(bool),class base::WeakPtr<class media::AudioRendererImpl> const &,bool &&)	C++
 	chrome_child.dll!base::internal::InvokeHelper<1,void>::MakeItSo<void ( media::AudioRendererImpl::*const &)(bool),class base::WeakPtr<class media::AudioRendererImpl> const &,bool>(void ( media::AudioRendererImpl::*const &)(bool),class base::WeakPtr<class media::AudioRendererImpl> const &,bool &&)	C++
 	chrome_child.dll!base::internal::Invoker<struct base::internal::BindState<void ( gpu::GpuWatchdogThread::*)(bool),class base::WeakPtr<class gpu::GpuWatchdogThread>,bool>,void >::Run(class base::internal::BindStateBase *)	C++
 	chrome_child.dll!base::debug::TaskAnnotator::RunTask(char const *,struct base::PendingTask *)	C++
 	chrome_child.dll!base::MessageLoop::RunTask(struct base::PendingTask *)	C++
 	chrome_child.dll!base::MessageLoop::DoWork(void)	C++
 	chrome_child.dll!base::MessagePumpDefault::Run(class base::MessagePump::Delegate *)	C++
 	chrome_child.dll!base::MessageLoop::Run(void)	C++
 	chrome_child.dll!base::RunLoop::Run(void)	C++
 	chrome_child.dll!base::Thread::Run(class base::RunLoop *)	C++
 	chrome_child.dll!base::Thread::ThreadMain(void)	C++
 	chrome_child.dll!base::PlatformThread::Sleep(class base::TimeDelta)	C++

If a layer's contributes_to_drawn_render_surface is false, it might not have valid draw properties (since draw_property_utils::LayerShouldBeSkippedForDrawPropertiesComputation might be true), and that could lead to an infinite loop when we try to use those draw properties. So you might need to change LayerShouldBeSkippedForDrawPropertiesComputation, and then also update ComputeInitialRenderSurfaceList so we still don't try to draw those layers.

The bug is in blink. We are getting a layer with 33554432x33554432 bounds. The above change simply caused us to create tiles for this layer which is going in an infinite loop.

+chrishtr@, pdr@, could anyone on blink take a look?

trchen@ This issue is marked as RB-Stable for M62, could you please let us know is there any latest update available on this issue?

Thanks!

Yes I found out the root cause and is working on it.

We are planning to continue with out M62 stable release tomorrow. Since this bug has been present in M61, not considering it as release blocker. If there is a fix, we can consider it for a future M62 respin. 

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

commit 5e2e7cb82506a44d766a182b335383f59155f325
Author: Tien-Ren Chen <trchen@chromium.org>
Date: Thu Oct 19 05:10:28 2017

[Blink] Fix oversized foreground layer when a child containment layer exists

Previously we create a child containment layer sized by
LayoutRect::InfiniteIntRect() when a layer has CSS clip-path. This is
because we used object.HasClipRelatedProperty() as the criteria, but the
layer only applies CSS clip and overflow clip. This confuses foreground
layer geometry computation, and resulted in an oversized foreground
layer.

This CL does the following things:

1. Change the criteria so that child containment layer is only created
when either CSS clip or overflow clip is present.

2. Simplify foreground layer and child containment layer geometry
computation, so that subpixel accumulation handling is more correct, and
also infer parameters from the parent graphics layer so the formula is
consistent for different layer hierarchy configuration.

BUG= 773536 

Cq-Include-Trybots: master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: Ic8074ef54270cdd2f628bc73f3bcb6fa929d8881
Reviewed-on: https://chromium-review.googlesource.com/722259
Commit-Queue: Tien-Ren Chen <trchen@chromium.org>
Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#510003}
[modify] https://crrev.com/5e2e7cb82506a44d766a182b335383f59155f325/third_party/WebKit/Source/core/layout/LayoutBox.cpp
[modify] https://crrev.com/5e2e7cb82506a44d766a182b335383f59155f325/third_party/WebKit/Source/core/layout/LayoutBox.h
[modify] https://crrev.com/5e2e7cb82506a44d766a182b335383f59155f325/third_party/WebKit/Source/core/layout/LayoutBoxTest.cpp
[modify] https://crrev.com/5e2e7cb82506a44d766a182b335383f59155f325/third_party/WebKit/Source/core/layout/VisualRectMappingTest.cpp
[modify] https://crrev.com/5e2e7cb82506a44d766a182b335383f59155f325/third_party/WebKit/Source/core/paint/compositing/CompositedLayerMapping.cpp
[modify] https://crrev.com/5e2e7cb82506a44d766a182b335383f59155f325/third_party/WebKit/Source/core/paint/compositing/CompositedLayerMapping.h
[modify] https://crrev.com/5e2e7cb82506a44d766a182b335383f59155f325/third_party/WebKit/Source/core/paint/compositing/CompositedLayerMappingTest.cpp
[modify] https://crrev.com/5e2e7cb82506a44d766a182b335383f59155f325/third_party/WebKit/Source/core/paint/compositing/PaintLayerCompositor.cpp

Your change meets the bar and is auto-approved for M63. Please go ahead and merge the CL to branch 3239 manually. Please contact milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), gkihumba@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Need clarification: Although it didn't block M62 from going stable, do we still want to bring it back to M62?

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

commit e6cb080f0f8d50e958de54bade38ab2f231ebfe9
Author: Tien-Ren Chen <trchen@chromium.org>
Date: Mon Oct 23 21:23:30 2017

[Blink] Fix oversized foreground layer when a child containment layer exists

Previously we create a child containment layer sized by
LayoutRect::InfiniteIntRect() when a layer has CSS clip-path. This is
because we used object.HasClipRelatedProperty() as the criteria, but the
layer only applies CSS clip and overflow clip. This confuses foreground
layer geometry computation, and resulted in an oversized foreground
layer.

This CL does the following things:

1. Change the criteria so that child containment layer is only created
when either CSS clip or overflow clip is present.

2. Simplify foreground layer and child containment layer geometry
computation, so that subpixel accumulation handling is more correct, and
also infer parameters from the parent graphics layer so the formula is
consistent for different layer hierarchy configuration.

BUG= 773536 
TBR=trchen@chromium.org

(cherry picked from commit 5e2e7cb82506a44d766a182b335383f59155f325)

Cq-Include-Trybots: master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: Ic8074ef54270cdd2f628bc73f3bcb6fa929d8881
Reviewed-on: https://chromium-review.googlesource.com/722259
Commit-Queue: Tien-Ren Chen <trchen@chromium.org>
Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#510003}
Reviewed-on: https://chromium-review.googlesource.com/734308
Reviewed-by: Tien-Ren Chen <trchen@chromium.org>
Cr-Commit-Position: refs/branch-heads/3239@{#166}
Cr-Branched-From: adb61db19020ed8ecee5e91b1a0ea4c924ae2988-refs/heads/master@{#508578}
[modify] https://crrev.com/e6cb080f0f8d50e958de54bade38ab2f231ebfe9/third_party/WebKit/Source/core/layout/LayoutBox.cpp
[modify] https://crrev.com/e6cb080f0f8d50e958de54bade38ab2f231ebfe9/third_party/WebKit/Source/core/layout/LayoutBox.h
[modify] https://crrev.com/e6cb080f0f8d50e958de54bade38ab2f231ebfe9/third_party/WebKit/Source/core/layout/LayoutBoxTest.cpp
[modify] https://crrev.com/e6cb080f0f8d50e958de54bade38ab2f231ebfe9/third_party/WebKit/Source/core/layout/VisualRectMappingTest.cpp
[modify] https://crrev.com/e6cb080f0f8d50e958de54bade38ab2f231ebfe9/third_party/WebKit/Source/core/paint/compositing/CompositedLayerMapping.cpp
[modify] https://crrev.com/e6cb080f0f8d50e958de54bade38ab2f231ebfe9/third_party/WebKit/Source/core/paint/compositing/CompositedLayerMapping.h
[modify] https://crrev.com/e6cb080f0f8d50e958de54bade38ab2f231ebfe9/third_party/WebKit/Source/core/paint/compositing/CompositedLayerMappingTest.cpp
[modify] https://crrev.com/e6cb080f0f8d50e958de54bade38ab2f231ebfe9/third_party/WebKit/Source/core/paint/compositing/PaintLayerCompositor.cpp

This bug requires manual review: Request affecting a post-stable build
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), bhthompson@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

trchen@ thanks for the fix! Since this issue has been present in M61, and we're now already rolling out stable, if this issue is not absolutely critical, I recommend waiting until M63. Thoughts?

I... don't know. I believe the issue is rare, but for users who are affected by this bug it is a 100% hang with no workaround.

Also since it manifests as renderer timeout than a crash, we probably won't get a very meaningful crash stats. i.e. it may be not as rare as we thought.

My two cents is that the CL is likely to reduce renderer hang, and the worst risk it could impose is to introduce incorrect rendering. I'm slightly leaning towards taking it to M62. WDYT?

Since we are already during M62 stable rollout and this bug was present in M61, I recommend waiting until M63. Is there a way we can get better estimates for the impact? 

Rechecked this issue on Windows 10, Mac 10.12.6, Ubuntu 14.04 using M63 chrome version 63.0.3239.18 and Canary M64 Version 64.0.3249.2(Windows) & 64.0.3249.0 for Mac and Linux. Fix is working as intended, No crash is observed when clicked on Animate button for the sample html file provided.

Tagging with TE-Verified labels.

Thanks.!

Sorry for the delayed reply. IMO if we can observe a spike in renderer hang during the regression range and it reduced significantly after the fix, then we should probably bring it to M62.

However I'm a noob with the crash tool. Any hint how to make queries to acquire said statistics?

Or how about closing it now and re-evaluate only if we get dupe bug reports?

There are 7813 crash reports with cc::PictureLayerTiling::CreateTile in the stack frame. Trying to get a faster query for more details, particularly on version.

So it certainly happens.

Loads slow but gives versions: https://crash.corp.google.com/browse?q=product.name%3D%27Chrome%27%20AND%20thread.StackTrace.StackFrame.FunctionName%3D%27cc%3A%3APictureLayerTiling%3A%3ACreateTile(cc%3A%3ATile%3A%3ACreateInfo%20const%20%26)%27&sql_dialect=dremelsql&ignore_case=false&enable_rewrite=false&omit_field_name=thread.StackTrace.StackFrame.FunctionName&omit_field_value=cc%3A%3APictureLayerTiling%3A%3ACreateTile(cc%3A%3ATile%3A%3ACreateInfo%20const%20%26)&omit_field_opt=%3D

There are a few crashes still in version that should have the patch, but not many. That is not very informative because the patch has not been live for very long.

I should point out that there have been no crashes/hangs in the M-63 channel containing the patch, which may not have rolled out yet. And only 1 in M-64 post patch from a client with a history of crashing in CreateTile.

Issue 778538 has been merged into this issue.

[Bulk Edit]
URGENT - PTAL.
M63 Stable promotion is coming soon and your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP. Thank you.

I think a new issue has arisen from this fix. In the same example file, there is a video playing within the '.inner' div. That video should be clipped with the rest of the '.inner' element. It is not being clipped properly. 

Re comment 38: please send us a reproducible example, via a new bug report.