Issue 682764 has been merged into this issue.

I am hitting this with a 100% repro rate when starting tab mirroring and do not have --vmodule=performance_metrics_overlay=3 in my command line (in fact no --vmodule flags at all).

See, e.g. https://crash.corp.google.com/browse?stbtiq=1106f62560000000

miu@, can we just remove this buggy code?

Note, when the extension process crashes this way, Chrome seems unable to restart it, so the entire Cast feature is left in a pretty bad state.

Weird. Despite the lack of --vmodule=..., it seems verbose logging for that .cc file *must* be turned on somehow. We know this because the MaybeRenderPerformanceMetricsOverlay() function would not attempt to write to any memory otherwise.

Though, I didn't see anything from the command line options listed in the crash report; so, I have no idea what's causing this for you.

Crash says the frequency of this is ridiculously low (and only for a total of 7 distinct users since Chrome 56).

Users experienced this crash on the following builds:

Linux Dev 59.0.3047.0 -  3.24 CPM, 6 reports, 1 clients (signature media::cast::`anonymous namespace'::RenderLineOfText)

If this update was incorrect, please add "Fracas-Wrong" label to prevent future updates.

- Go/Fracas

Users experienced this crash on the following builds:

Linux Beta 58.0.3029.33 -  1.66 CPM, 8 reports, 1 clients (signature media::cast::`anonymous namespace'::RenderLineOfText)

If this update was incorrect, please add "Fracas-Wrong" label to prevent future updates.

- Go/Fracas

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

commit dcb83c6cb421c934ca933260391390ad5038bb70
Author: miu <miu@chromium.org>
Date: Mon Mar 27 21:21:29 2017

Crash Fix (Cast Streaming): Render overlay on copy of source frame.

Due to major overhaul going on in the Video Capture stack, the video
frames sent to the render process have become read-only (they used to be
read-write). The "performance overlay" debugging utility would just
modify pixels on source video frames, and in the new world this caused a
page fault. Solution: Now, it must first make a copy of the frame.

BUG= 677341 

Review-Url: https://codereview.chromium.org/2775993002
Cr-Commit-Position: refs/heads/master@{#459882}

[modify] https://crrev.com/dcb83c6cb421c934ca933260391390ad5038bb70/media/cast/sender/performance_metrics_overlay.cc
[modify] https://crrev.com/dcb83c6cb421c934ca933260391390ad5038bb70/media/cast/sender/performance_metrics_overlay.h
[modify] https://crrev.com/dcb83c6cb421c934ca933260391390ad5038bb70/media/cast/sender/video_sender.cc

Just to make sure that the change in behavior (from previously read-write to now read-only) was intentional, I would like to understand where exactly this happened. I don't think I intended to make such a change in any of my CLs. Could this have happened as part of converting the Browser/Renderer boundary to Mojo?

chfremer: Not sure. IIRC, you switched to using Mojo to create the shared memory, right?

The work of migrating the Browser/Renderer boundary from Chromium IPC to Mojo was actually done by mcasas@ (+cc).

I would really like to understand the root cause of this crash, just to make sure there is no other issue we don't know about.

Here, it's RW, which makes sense because we have to be able to write into the shmem in the browser process: https://cs.chromium.org/chromium/src/media/capture/video/shared_memory_buffer_tracker.cc?rcl=34662d716488c15221573880f3462b1a3e2c123c&l=38

Here, in the renderer process, we ignore whether Mojo thinks the memory is RO or RW, and create base::SharedMemory with the read-only flag set: https://cs.chromium.org/chromium/src/content/renderer/media/video_capture_impl.cc?rcl=d9d08ba6477548fb48ce55cd1939b082d71b693c&l=252

So, yes, the behavior did change sometime in the past (https://chromiumcodereview.appspot.com/2410383002). As for whether it's a good change: I personally think it is: It ensures that "resurrected frames" will be valid because previous uses of them could not have modified their content. The downside is that, if any consumer needs to modify a frame, it will have to make a copy first; and that's a significant performance and resource issue. However, since there can be multiple consumers of the same frame, it's a very good thing that our data model ensures the memory is RO.

All said, if our little debugging utility in Cast Streaming was the only thing to have been broken, then I think we're in a good state. ;-)

Thanks miu@. I now understand where it was changed and how this has caused the crash.

Agreed that read-only is probably the right choice, and requiring consumers that want to modify frames to make a copy seems reasonable.