This crash occurs very frequently on windows platform and is likely preventing the fuzzer webDEViL_webgl from making much progress. Fixing this will allow more bugs to be found.

Marking this bug as a blocker for next Beta release.

If this is incorrect, please add ClusterFuzz-Wrong label and remove the ReleaseBlock-Beta label.

Automatically applying components based on crash stacktrace and information from OWNERS files.

If this is incorrect, please apply the Test-Predator-Wrong-Components label.

Antoine, are you a right owner for this? Could you please take a look?

I'll take a look. The variables on that line are all initialized, so maybe they're taking an uninitialized value from somewhere, although it's also possible that they're taking a value from shared memory which msan doesn't know about?

I should also note, it looks like the browser is getting killed while the compositor context being initialized (from the logs:
[1:10:0100/000000.984652:ERROR:broker_posix.cc(39)] Recvmsg error: Connection reset by peer (104)
[1:10:0100/000000.042964:ERROR:implementation_base.cc(188)] ContextResult::kFatalFailure: TransferBuffer::Initialize() failed
), and while we need to handle this gracefully, it's almost certain that the renderer can't do much at that point.
It also likely explains the poor reproducibility, because this stems from a race.

The uninitialized value is actually a UAF, introduced in https://chromium-review.googlesource.com/c/chromium/src/+/952080 . If initialization fails at the wrong point, we keep a GLES2Implementation alive but destroy the CommandBufferHelper it uses. Should be an easy fix.

https://chromium-review.googlesource.com/c/chromium/src/+/983132 has the fix.

A friendly reminder that M67 branch is coming soon on 04/12! Your bug is labelled as Beta ReleaseBlock, pls make sure to land the fix ASAP to trunk. This way we branch M67 from a high quality trunk. Thank you.

Thanks for the fix Antoine!

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

commit 4388b4ad02daa01ffee5c7b70699801bf7e15b73
Author: Antoine Labour <piman@chromium.org>
Date: Wed Mar 28 13:17:09 2018

Fix UAF in ContextProviderCommandBuffer in failure case

If GLES2Implementation fails to initialize, we would keep it around, but
destroy the CommandBufferHelper that it needs.
Instead, make sure we always keep both, or neither.

Bug:  826389 
Change-Id: I3167e4e113235e28b23a029bd106746e0bead073
Reviewed-on: https://chromium-review.googlesource.com/983132
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Reviewed-by: Jonathan Backer <backer@chromium.org>
Commit-Queue: Jonathan Backer <backer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#546468}
[modify] https://crrev.com/4388b4ad02daa01ffee5c7b70699801bf7e15b73/services/ui/public/cpp/gpu/context_provider_command_buffer.cc

High severity since this is a use-after-free.

Trunk churn - found by many fuzzers.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

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