Issue metadata
Sign in to add a comment
|
Renderer goes into infinite loop while checking out from Apple Store |
||||||||||||||||||||||
Issue descriptionGoogle Chrome 67.0.3364.0 (Official Build) canary (64-bit) Revision 92107f0efb261174280c88aaac88e3cd64469793-refs/heads/master@{#541279} OS: macOS 10.13.4 What steps will reproduce the problem? (1) Go to corporate perks site (2) From there, go to store.apple.com (3) Add something to cart like a phone (4) Attempt to change location during checkout What is the expected result? Expect to be able to search for a new location. What happens instead? Renderer goes into infinite loop inside the compositor, continuously allocating memory. Had to kill the renderer process. Not sure whether this is reproducible. A couple of relevant screenshots and a symbolized sample output are attached. Abbreviated stack trace of the thread which was busy-looping follows. 6730 Thread_1994648: Compositor + 6730 thread_start (in libsystem_pthread.dylib) + 13 [0x7fff5b4f6c5d] + 6730 _pthread_start (in libsystem_pthread.dylib) + 377 [0x7fff5b4f756d] + 6730 _pthread_body (in libsystem_pthread.dylib) + 340 [0x7fff5b4f76c1] + 6730 base::(anonymous namespace)::ThreadFunc(void*) (in Google Chrome Framework) load address 0x10e951000 + 0x20f24a7 [platform_thread_posix.cc:78] + 6730 base::Thread::ThreadMain() (in Google Chrome Framework) load address 0x10e951000 + 0x20f44bb [lock.h:26] + 6730 <name omitted> (in Google Chrome Framework) load address 0x10e951000 + 0x20c2d25 [run_loop.cc:139] + 6730 base::MessagePumpDefault::Run(base::MessagePump::Delegate*) (in Google Chrome Framework) load address 0x10e951000 + 0x209d6e9 [message_pump_default.cc:37] + 6730 base::MessageLoop::DoWork() (in Google Chrome Framework) load address 0x10e951000 + 0x209cc98 [message_loop.cc:451] + 6730 base::MessageLoop::RunTask(base::PendingTask*) (in Google Chrome Framework) load address 0x10e951000 + 0x209c7b4 [vector:639] + 6730 base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*) (in Google Chrome Framework) load address 0x10e951000 + 0x2077da8 [callback_forward.h:11] + 6730 blink::scheduler::internal::ThreadControllerImpl::DoWork(blink::scheduler::internal::SequencedTaskSource::WorkType) (in Google Chrome Framework) load address 0x10e951000 + 0x1b7156f [weak_ptr.h:243] + 6730 base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*) (in Google Chrome Framework) load address 0x10e951000 + 0x2077da8 [callback_forward.h:11] + 6730 cc::ProxyImpl::NotifyReadyToCommitOnImpl(cc::CompletionEvent*, cc::LayerTreeHost*, base::TimeTicks, bool) (in Google Chrome Framework) load address 0x10e951000 + 0x2f5943c [trace_event.h:1106] + 6730 cc::Scheduler::NotifyReadyToCommit() (in Google Chrome Framework) load address 0x10e951000 + 0x2edb8ac [trace_event.h:1106] + 6730 cc::Scheduler::ProcessScheduledActions() (in Google Chrome Framework) load address 0x10e951000 + 0x2edaff8 [scheduler.cc:743] + 6730 cc::ProxyImpl::ScheduledActionCommit() (in Google Chrome Framework) load address 0x10e951000 + 0x2f5b23a [proxy_impl.cc:155] + 6730 cc::LayerTreeHostImpl::CommitComplete() (in Google Chrome Framework) load address 0x10e951000 + 0x2f23346 [layer_tree_host_impl.cc:382] + 6730 cc::LayerTreeHostImpl::UpdateSyncTreeAfterCommitOrImplSideInvalidation() (in Google Chrome Framework) load address 0x10e951000 + 0x2f23482 [layer_tree_host_impl.cc:4758] + 6730 cc::LayerTreeImpl::UpdateDrawProperties(bool) (in Google Chrome Framework) load address 0x10e951000 + 0x2f3abfe [layer_tree_impl.cc:1141] + 6730 cc::PictureLayerImpl::UpdateTiles() (in Google Chrome Framework) load address 0x10e951000 + 0x2eac787 [picture_layer_impl.cc:650] + 6730 cc::PictureLayerTilingSet::UpdateTilePriorities(gfx::Rect const&, float, double, cc::Occlusion const&, bool) (in Google Chrome Framework) load address 0x10e951000 + 0x2ef408c [iterator:1371] + 6730 cc::PictureLayerTiling::ComputeTilePriorityRects(gfx::Rect const&, gfx::Rect const&, gfx::Rect const&, gfx::Rect const&, float, cc::Occlusion const&) (in Google Chrome Framework) load address 0x10e951000 + 0x2ef141f [picture_layer_tiling.cc:600] + 6130 cc::PictureLayerTiling::SetLiveTilesRect(gfx::Rect const&) (in Google Chrome Framework) load address 0x10e951000 + 0x2ef0724 [picture_layer_tiling.cc:667] + ! 3807 cc::PictureLayerTiling::CreateTile(cc::Tile::CreateInfo const&) (in Google Chrome Framework) load address 0x10e951000 + 0x2eeead5 [memory:2636] + ! : 856 std::__1::unordered_map<cc::TileMapKey, std::__1::unique_ptr<cc::Tile, std::__1::default_delete<cc::Tile> >, cc::TileMapKeyHash, std::__1::equal_to<cc::TileMapKey>, std::__1::allocator<std::__1::pair<cc::TileMapKey const, std::__1::unique_ptr<cc::Tile, std::__1::default_delete<cc::Tile> > > > >::operator[](cc::TileMapKey const&) (in Google Chrome Framework) load address 0x10e951000 + 0x2eeeb93 [__hash_table:2008] + ! : 815 std::__1::unordered_map<cc::TileMapKey, std::__1::unique_ptr<cc::Tile, std::__1::default_delete<cc::Tile> >, cc::TileMapKeyHash, std::__1::equal_to<cc::TileMapKey>, std::__1::allocator<std::__1::pair<cc::TileMapKey const, std::__1::unique_ptr<cc::Tile, std::__1::default_delete<cc::Tile> > > > >::operator[](cc::TileMapKey const&) (in Google Chrome Framework) load address 0x10e951000 + 0x2eeebb8 [__hash_table:102] + ! : 592 std::__1::unordered_map<cc::TileMapKey, std::__1::unique_ptr<cc::Tile, std::__1::default_delete<cc::Tile> >, cc::TileMapKeyHash, std::__1::equal_to<cc::TileMapKey>, std::__1::allocator<std::__1::pair<cc::TileMapKey const, std::__1::unique_ptr<cc::Tile, std::__1::default_delete<cc::Tile> > > > >::operator[](cc::TileMapKey const&) (in Google Chrome Framework) load address 0x10e951000 + 0x2eeeb98 [__hash_table:0] + ! : 514 std::__1::unordered_map<cc::TileMapKey, std::__1::unique_ptr<cc::Tile, std::__1::default_delete<cc::Tile> >, cc::TileMapKeyHash, std::__1::equal_to<cc::TileMapKey>, std::__1::allocator<std::__1::pair<cc::TileMapKey const, std::__1::unique_ptr<cc::Tile, std::__1::default_delete<cc::Tile> > > > >::operator[](cc::TileMapKey const&) (in Google Chrome Framework) load address 0x10e951000 + 0x2eeebfb [new:230] + ! : | 483 operator new(unsigned long) (in libc++abi.dylib) + 40 [0x7fff592f3628] + ! : | + 458 malloc (in libsystem_malloc.dylib) + 24 [0x7fff5b41350b] + ! : | + ! 419 malloc_zone_malloc (in libsystem_malloc.dylib) + 103 [0x7fff5b414201] + ! : | + ! : 379 base::allocator::MallocZoneFunctionsToReplaceDefault()::$_1::__invoke(_malloc_zone_t*, unsigned long) (in Google Chrome Framework) load address 0x10e951000 + 0x2122aad [allocator_shim.cc:178] + ! : | + ! : | 299 base::allocator::MallocZoneFunctionsToReplaceDefault()::$_1::__invoke(_malloc_zone_t*, unsigned long) (in Google Chrome Framework) load address 0x10e951000 + 0x2122aad [allocator_shim.cc:178] + ! : | + ! : | + 176 szone_malloc_should_clear (in libsystem_malloc.dylib) + 1288,94,... [0x7fff5b414765,0x7fff5b4142bb,...] + ! : | + ! : | + 99 szone_malloc_should_clear (in libsystem_malloc.dylib) + 422 [0x7fff5b414403] + ! : | + ! : | + ! 68 tiny_malloc_from_free_list (in libsystem_malloc.dylib) + 978,0,... [0x7fff5b4155a7,0x7fff5b4151d5,...] + ! : | + ! : | + ! 31 tiny_malloc_from_free_list (in libsystem_malloc.dylib) + 431 [0x7fff5b415384] + ! : | + ! : | + ! 31 set_tiny_meta_header_in_use (in libsystem_malloc.dylib) + 44,54,... [0x7fff5b42bed4,0x7fff5b42bede,...] + ! : | + ! : | + 5 szone_malloc (in libsystem_malloc.dylib) + 2,0 [0x7fff5b414257,0x7fff5b414255] + ! : | + ! : | + 3 base::allocator::(anonymous namespace)::MallocImpl(base::allocator::AllocatorDispatch const*, unsigned long, void*) (in Google Chrome Framework) load address 0x10e951000 + 0x2122d91 [malloc_zone_functions_mac.h:94] + ! : | + ! : | + 3 szone_malloc_should_clear (in libsystem_malloc.dylib) + 2903 [0x7fff5b414db4] + ! : | + ! : | + ! 3 mvm_allocate_pages_securely (in libsystem_malloc.dylib) + 276 [0x7fff5b423207] + ! : | + ! : | + ! 3 mach_vm_map (in libsystem_kernel.dylib) + 80 [0x7fff5b3bab4d] + ! : | + ! : | + ! 3 _kernelrpc_mach_vm_map_trap (in libsystem_kernel.dylib) + 10 [0x7fff5b3b270e] + ! : | + ! : | + 2 base::allocator::(anonymous namespace)::MallocImpl(base::allocator::AllocatorDispatch const*, unsigned long, void*) (in Google Chrome Framework) load address 0x10e951000 + 0x2122d20 [allocator_shim_default_dispatch_to_mac_zoned_malloc.cc:17] + ! : | + ! : | + 2 base::allocator::(anonymous namespace)::MallocImpl(base::allocator::AllocatorDispatch const*, unsigned long, void*) (in Google Chrome Framework) load address 0x10e951000 + 0x2122d24 [allocator_shim_default_dispatch_to_mac_zoned_malloc.cc:17] ...
,
Mar 10 2018
,
Mar 10 2018
,
Mar 10 2018
Unfortunately this has been broken for a while. It's broken in current Stable, too: Google Chrome 64.0.3282.186 (Official Build) (64-bit) Revision 9611116ee79c63602f452e4fae2242a61cf0672d-refs/branch-heads/3282@{#694}
,
Mar 12 2018
,
Mar 16 2018
Assigning to ccameron for further triage of mac compositing bug.
,
Mar 16 2018
Stacks looks like a scheduling or tile management issue, nothing mac-specific is on the stack. Have we tried to reproduce on Linux or Windows (controlling for things like HiDPI, etc)?
,
Mar 16 2018
Haven't had a chance to try on other OSs with a high-DPI display. Agree it's likely not Mac-specific. It's 100% reproducible so if someone with access to such a machine could give that a try, appreciated.
,
Mar 21 2018
It's reproducable on TOT Linux without high dpi. Just go to store.apple.com, add to cart, checkout, continue as guest, ask to pick up and it shows a map, type a city name in and press enter, the map tries to zoom in on some place and it freezes. I can't see threads with gdb so I can't look at what it's doing easily :( Warning: couldn't activate thread debugging using libthread_db: Cannot find new threads: debugger service failed warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.
,
Mar 21 2018
It eventually crashes from OOM ../../third_party/tcmalloc/chromium/src/central_freelist.cc:319] tcmalloc: allocation failed 4096 [1:10:0321/141619.503884:FATAL:memory_linux.cc(36)] Out of memory. #0 0x7fa6ad75649c base::debug::StackTrace::StackTrace() #1 0x7fa6ad78063b logging::LogMessage::~LogMessage() #2 0x7fa6ad7bc345 base::(anonymous namespace)::OnNoMemory() #3 0x7fa6ad849742 GlibcMallocHook #4 0x7fa6adc15dca operator new() #5 0x7fa6a9c120fc cc::TileManager::CreateTile() #6 0x7fa6a9b8fc32 cc::PictureLayerImpl::CreateTile() #7 0x7fa6a9bf51e7 cc::PictureLayerTiling::CreateTile() #8 0x7fa6a9bf78aa cc::PictureLayerTiling::SetLiveTilesRect() #9 0x7fa6a9bf8b0f cc::PictureLayerTiling::ComputeTilePriorityRects() #10 0x7fa6a9bfcd9c cc::PictureLayerTilingSet::UpdateTilePriorities() #11 0x7fa6a9b8e242 cc::PictureLayerImpl::UpdateTiles() #12 0x7fa6a9c563cf cc::LayerTreeImpl::UpdateDrawProperties() #13 0x7fa6a9c394e6 cc::LayerTreeHostImpl::UpdateSyncTreeAfterCommitOrImplSideInvalidation() #14 0x7fa6a9c39279 cc::LayerTreeHostImpl::CommitComplete() #15 0x7fa6a9c7e7cf cc::ProxyImpl::ScheduledActionCommit()
,
Mar 21 2018
It looks like the map zooms in but compositor believes that the entire map is still visible. So it just starts making tiles at a high level of zoom for the entire planet: 2064 tiles across, one row at a time.
,
Mar 21 2018
weiliang can you have a look? It would boil down to a clipping problem, which sounds like property trees?
,
Apr 13 2018
weiliang, have you had a chance to look at this yet? Reminder: this is ReleaseBlock-Stable for M67, beta promotion is on Apr 26, and stable cut is on May 24.
,
Apr 16 2018
Looking. Right now it seem to be from one layer scaled to 512. Maybe we should just cap the scale for transform.
,
Apr 16 2018
That would give an incorrect result, though as the map won't look right then. I think the problem is the clip isn't respecting the scale.
,
Apr 16 2018
By scale I mean the ideal_contents_scale calculated here: https://cs.chromium.org/chromium/src/cc/layers/layer_impl.cc?gsn=viewport_rect_for_tile_priority_in_content_space_&l=878 The visible rects from the layers seems reasonable, just with a 512 ideal_contents_scale, all the tile priority rects are huge. Since we seem to already cap the ideal_contents_scale for perspective, capping it for large transform seems reasonable too?
,
Apr 16 2018
But the rests are large because it's not being clipped correctly, or no? Like only a small part of the layer (~4 tiles?) is visible, even though at that scale there are many /possible/ tiles.
,
Apr 16 2018
rects*
,
Apr 16 2018
What I see is we have layer w/ visible rect in layer space 0,0 1843x1382, and ideal contents scale 512, which makes its visible rect in content space 0,0 943616x707584... I am not sure where we are supposed to apply the clip?
,
Apr 16 2018
Hrm, but if you look at what the page is doing, there is a map layer of which only a small part of it is visible. I assume that visible area is 1843x1382? If the scale was -512 then you'd expect the visible area to grow, as more pixels fit into that window. But as it is +512, you'd expect the visible area to effectively shrink instead as it grows and pushes more "layer space pixels" out of that window?
,
Apr 16 2018
Wait I know what's wrong: Here: https://cs.chromium.org/chromium/src/cc/layers/picture_layer_impl.cc?sq=package:chromium&l=651 we passed in a rect called viewport_rect_for_tile_priority_in_content_space_. Which is calling here: https://cs.chromium.org/chromium/src/cc/tiles/picture_layer_tiling_set.cc?sq=package:chromium&l=524 where we take in a rect called visible_rect_in_layer_space ........so we ended up applying content scale twice.
,
Apr 16 2018
I am curious tho if that will fix the problem or just reduce it by a factor of 2. If the clip is a small window and you scale up the layer, the number of pixels being clipped doesn't change (and decreases in layer space).
,
Apr 16 2018
I think the clip should be taken into account in the visible_layer_rect calculation. Should happen prior to calculating the rects for tile manager. If pass in visible layer rect into that function the page doesn't freeze and crash. Though I also see that when the visible_rect is empty we try using device viewport (after transform) to pass into tile manager.
,
Apr 16 2018
> If pass in visible layer rect into that function the page doesn't freeze and crash. Does the visible rect in the tiling's space match how many pixels are visible?
,
Apr 17 2018
> Does the visible rect in the tiling's space match how many pixels are visible? Yeah they should. I could check/look for unit test.
,
Apr 24 2018
Listing of findings: In update tiles: https://cs.chromium.org/chromium/src/cc/layers/picture_layer_impl.cc?sq=package:chromium&l=652 We have a that is visible_layer_rect, scaled by ideal_contents_scale, and the ideal_contents_scale is affected by the transform applied to the layer, which turns out to be 512 in this case. Mask layers don't calculate their visible layer rect, but just use bounds: https://cs.chromium.org/chromium/src/cc/trees/draw_property_utils.cc?sq=package:chromium&l=1006 This makes sense for single tile mask, but needs to be updated for tiled mask layer. Also need to adjust append quad's scale for tiled mask layer: https://cs.chromium.org/chromium/src/cc/layers/render_surface_impl.cc?sq=package:chromium&l=457
,
Apr 24 2018
As to why this didn't happen before with single mask is because we limit render surface size by max_texture_size (2048x2048): https://cs.chromium.org/chromium/src/cc/layers/render_surface_impl.cc?q=calculatecontentrect&sq=package:chromium&l=272
,
Apr 24 2018
I'm not sure what exactly what is the right fix because in our current implementation there would always be edge cases of a unclipped mask layer scaled too large. Maybe we could clamp the visible size by device view port?
,
Apr 25 2018
M67 Stable promotion is coming soon. Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and request a merge into the release branch ASAP. Thank you.
,
May 2 2018
*** Bulk Edit *** M67 Stable promotion is coming soon. Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and request a merge into the release branch ASAP. If fix is already merged to M67 and nothing else is pending, pls mark the bug as fixed. Thank you.
,
May 7 2018
*** Bulk Edit *** M67 Stable promotion is coming VERY soon. Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and request a merge into the release branch ASAP. If fix is already merged to M67 and nothing else is pending, pls mark the bug as fixed. Thank you.
,
May 10 2018
*** Bulk Edit *** M67 Stable promotion is coming VERY soon. Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and request a merge into the release branch ASAP. If fix is already merged to M67 and nothing else is pending, pls mark the bug as fixed. Thank you.
,
May 11 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/73fe3c43758e89fe7214aac25293f7e71c4bda55 commit 73fe3c43758e89fe7214aac25293f7e71c4bda55 Author: Weiliang Chen <weiliangc@chromium.org> Date: Fri May 11 19:52:37 2018 cc: Compute |visible_rect| for tiled mask layers to limit raster For single tile mask layers |visible_rect| is only used as bool to check for non empty. For tiled mask layers correct |visible_rect| is needed to limit the amount of resource we generated for raster the tiled masks. This bug was discovered when we have a tiled mask layer with big scale and we try to create tiles to covered enlarged space and eventually OOM. Compute |visible_rect| correctly results in breaking the assumption that tiled mask layer's |to_target| is only a scale. This changes the computation in |RenderSurfaceImpl| of how to convert tile quads into tiled mask render pass quads. This CL is aimed to fix release blocking bug and thus has limited scoped. There are two potential follow-ups: check for scale of tiled mask layer, and adjust render surface rect. For scale check: ideally tiled mask layer should be in the same space as the render surface, this should simplify computation when converting from tiled quads to render pass quads. For render surface rect: it does not make sense for render surface to have different size than the mask layer's visible rect. Right now render surfaces are unclipped and bounded by maxium texture size, while tiled mask visible size is clipped. To make these two sizes match there needs more investigation into whether unit tests still make sense, and should be in another CL. R=danakj Bug: 820727 Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel Change-Id: I62c7c992d99088c1f8cdbe4ffbac520b0a7d1a53 Reviewed-on: https://chromium-review.googlesource.com/1037629 Commit-Queue: weiliangc <weiliangc@chromium.org> Reviewed-by: danakj <danakj@chromium.org> Cr-Commit-Position: refs/heads/master@{#557985} [modify] https://crrev.com/73fe3c43758e89fe7214aac25293f7e71c4bda55/cc/BUILD.gn [modify] https://crrev.com/73fe3c43758e89fe7214aac25293f7e71c4bda55/cc/layers/picture_layer_impl.h [modify] https://crrev.com/73fe3c43758e89fe7214aac25293f7e71c4bda55/cc/layers/render_surface_impl.cc [modify] https://crrev.com/73fe3c43758e89fe7214aac25293f7e71c4bda55/cc/layers/render_surface_impl.h [modify] https://crrev.com/73fe3c43758e89fe7214aac25293f7e71c4bda55/cc/layers/render_surface_impl_unittest.cc [modify] https://crrev.com/73fe3c43758e89fe7214aac25293f7e71c4bda55/cc/layers/render_surface_unittest.cc [modify] https://crrev.com/73fe3c43758e89fe7214aac25293f7e71c4bda55/cc/trees/draw_property_utils.cc [modify] https://crrev.com/73fe3c43758e89fe7214aac25293f7e71c4bda55/cc/trees/draw_property_utils.h [modify] https://crrev.com/73fe3c43758e89fe7214aac25293f7e71c4bda55/cc/trees/layer_tree_host_unittest.cc [add] https://crrev.com/73fe3c43758e89fe7214aac25293f7e71c4bda55/cc/trees/layer_tree_host_unittest_masks.cc
,
May 11 2018
Psl request a merge to M67 once Cl listed at #33 is well baked/verified in canary and safe to merge to M67.
,
May 14 2018
The NextAction date has arrived: 2018-05-14
,
May 14 2018
Able to reproduce this issue on build without fix(67.0.3364.0). Hence verifying the issue on latest canary 68.0.3430.0 using Mac 10.13.3 Still seeing page unresponsive, clicking on close/selecting other address doesn't change anything. Attaching screencast for reference. @weiliangc: Please check the screencast and let us know if we miss anything. Please help in verifying the fix. Thanks!
,
May 14 2018
I checked myself, looks like apple changed their design of the page and they no longer use a map and mask. I'm on a M66 and couldn't see the map either.
,
May 14 2018
Removing release blocker tag and lower priority since the bug is no longer on the apple page.
,
May 30 2018
Well this is fixed but I don't have a repro case any more. Closing it. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by kbr@chromium.org
, Mar 10 2018