Crash type 3 in 0.23.79 #15025
Comments
Removing these patches from browser_plugin.cc: - bbf2817 - 416dc9c Most of the above patches have already been removed (after single webview) from browser_plugin.cc Chromium 68 has a few patches related to surface synchronization, such as this: https://chromium.googlesource.com/chromium/src/+/98d76dade64f938d939b7930e1de5460b564c2e2%5E%21/ The above Muon patches were to solve brave/browser-laptop#13982 I compiled this change in release mode + ran with 25 tabs (switching tabs with mouse/keyboard). I quit, relaunched, etc. Also turned off tab preview + used debug menu to manually discard tabs and switch back to them. Didn't notice any of the webviews get locked Not sure if this solves the problem, but this patch might not be needed anymore Auditors: @bridiver, @petemill
|
Here's the block of code that's failing (line that crashes bolded): void ClientLayerTreeFrameSink::SubmitCompositorFrame(CompositorFrame frame) {
DCHECK_CALLED_ON_VALID_THREAD(thread_checker_);
DCHECK(compositor_frame_sink_ptr_);
DCHECK(frame.metadata.begin_frame_ack.has_damage);
DCHECK_LE(BeginFrameArgs::kStartingFrameNumber,
frame.metadata.begin_frame_ack.sequence_number);
if (!enable_surface_synchronization_) {
local_surface_id_ =
local_surface_id_provider_->GetLocalSurfaceIdForFrame(frame);
} else {
if (local_surface_id_ == last_submitted_local_surface_id_) {
CHECK_EQ(last_submitted_device_scale_factor_,
frame.device_scale_factor());
CHECK_EQ(last_submitted_size_in_pixels_.height(),
frame.size_in_pixels().height());
CHECK_EQ(last_submitted_size_in_pixels_.width(),
frame.size_in_pixels().width());
}
}
// ...
From my investigation, it seems possible that surface sync might not be working as expected and this check is what fails. In our existing Muon codebase, we have a patch in place to disable Patch is viewable at brave/muon@0df5c9b |
bsclifton
modified the milestones:
0.23.x Release 5 (Release Channel),
0.23.x Release 6
I tested this for ~30 minutes doing resizing / minimizing / maximizing content (including video playing) and did not notice any video tearing or stetching Auditors: @bridiver
Should fix brave/browser-laptop#15025 I tested this for ~30 minutes doing resizing / minimizing / maximizing content (including video playing) and did not notice any video tearing or stetching Auditors: @bridiver
Should fix brave/browser-laptop#15025 I tested this for ~30 minutes doing resizing / minimizing / maximizing content (including video playing) and did not notice any video tearing or stetching Auditors: @bridiver, @darkdh
|
fixed in muon 8.0.9 |
|
@bsclifton is there anything QA can do here? I don't think we ever received/found a reproducible case that we can use. Is there any area of the browser that we should keep a close eye on when going through the the passes? |
bsclifton
added
release-notes/include
QA/test-plan-required
QA/test-plan-specified
and removed
QA/test-plan-required
labels
|
Verification Passed on Windows 10 x64 (@srirambv):
Also went through the above STR on
Passed with macOS 10.12.6 using the following build:
Passed on Ubuntu 17.10 x64 using the following build:
Passed on
|
Test plan
Checks that can be done BEFORE releasing
Checks that can be done AFTER releasing
Top Crash Reasonsand look for 0.23.105 with the errorviz::ClientLayerTreeFrameSink::SubmitCompositorFrame(viz::CompositorFrame)Full crash dump available here:
dump3.txt
The text was updated successfully, but these errors were encountered: