New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 817827 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: May 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 3
Type: Bug

Blocking:
issue 760181



Sign in to add a comment

Surface Invariants Error in Viz NavigationControllerBrowserTest.FrameNavigationEntry_RecreatedSubframeBackForward

Project Member Reported by jonr...@chromium.org, Mar 1 2018

Issue description

OS: Mac
Viz Enabled (--enable-features=VizDisplayCompositor)
Test Suite: content_browsertests
Test: NavigationControllerBrowserTest.FrameNavigationEntry_RecreatedSubframeBackForward

I'm seeing a consistent Surface Invariants failure on this test:
root_compositor_frame_sink_impl.cc(121)] SubmitCompositorFrame failed for LocalSurfaceId(3, 1, 36A6...) because Surface invariants violation
[90190:775:0301/115254.304637:FATAL:client_layer_tree_frame_sink.cc(221)] Surface invariants violation
0   libbase.dylib                       0x0000000109cad46e base::debug::StackTrace::StackTrace(unsigned long) + 174
1   libbase.dylib                       0x0000000109cad52d base::debug::StackTrace::StackTrace(unsigned long) + 29
2   libbase.dylib                       0x0000000109cab9ac base::debug::StackTrace::StackTrace() + 28
3   libbase.dylib                       0x0000000109d4521c logging::LogMessage::~LogMessage() + 460
4   libbase.dylib                       0x0000000109d42f65 logging::LogMessage::~LogMessage() + 21
5   libclient.dylib                     0x000000013cdf5902 viz::ClientLayerTreeFrameSink::OnMojoConnectionError(unsigned int, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) + 210
 ..... mojo pipe + runloop stack below ......

Hey ccameron@ and fsamuel@ would you know who can best look into a Surface Invariants crash on Mac?
 
Labels: OS-Mac
Is this recent? 
This was happening on March 1st ToT, with about 20 tests in total across content_browsertests and browser_tests exhibiting this failure.
I can take a look ... it might be easier to debug after r540971, since the crash should be local then.

Comment 5 by tapted@chromium.org, Mar 12 2018

Cc: jonr...@chromium.org
Owner: ccameron@chromium.org
Status: Assigned (was: Untriaged)
[mac triage] taking out of triage based on #c4.
Cc: kylec...@chromium.org samans@chromium.org
Ping Chris! This is a CQ and Finch blocker potentially.
Bug here is that we are not using a consistent ParentLocalSurfaceIdAllocator for the ui::Compositor -- we have scoped it to the RecyclableCompositor...
Project Member

Comment 8 by bugdroid1@chromium.org, May 5 2018

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

commit 0868b9fba1a5345f77eaddee52bd93d693fbe629
Author: Christopher Cameron <ccameron@chromium.org>
Date: Sat May 05 19:10:35 2018

viz/mac: Fix surface invariants violation by recycled compositors

RecyclableCompositorMac owns a ui::Compositor, but the surface id
generation was owned by BrowserCompositorMac.

A RecyclableCompositorMac will be recycled by many different
BrowserCompositorMac, and as a result, it may have a non-monotonic-
increasing surface id.

Scope the surface id information to RecyclableCompositorMac, and
throw some of the related logic into a helper function.

Bug: 772576,  817827 
Change-Id: Ic4299afa5670c96b51260917a3fafb2b692b3465
Reviewed-on: https://chromium-review.googlesource.com/1046045
Reviewed-by: Fady Samuel <fsamuel@chromium.org>
Reviewed-by: ccameron <ccameron@chromium.org>
Commit-Queue: ccameron <ccameron@chromium.org>
Cr-Commit-Position: refs/heads/master@{#556342}
[modify] https://crrev.com/0868b9fba1a5345f77eaddee52bd93d693fbe629/content/browser/renderer_host/browser_compositor_view_mac.h
[modify] https://crrev.com/0868b9fba1a5345f77eaddee52bd93d693fbe629/content/browser/renderer_host/browser_compositor_view_mac.mm

Status: Fixed (was: Assigned)

Sign in to add a comment