I see this crash both when using Slack and when using Chrome Remote Desktop

crash/dfc550869f942503 
crash/aff24b01c29f5a96 

Crash seems to be here:
540	wangxianzhu	2 months	    for (const auto& item : current_paint_artifact_->GetDisplayItemList()) {
541	wangxianzhu	2 months	      const auto& client = item.Client();
542	wangxianzhu	2 months	      client.ClearPartialInvalidationVisualRect();

(that last line)

Maybe client has been deleted...?

Thanks, yeah, I saw this stack trace too. Haven't figured this out yet...

In a debug build, this DCHECKs here:
    DCHECK(cached_item->Client().IsAlive());
in PaintController::CopyCachedSubsequence

And now I got this one...
[17296:20168:0827/152622.867:FATAL:paint_controller.cc(242)] Check failed: false. DisplayItem {
  "id": "0000015883F88EF0:DrawingPaintPhaseForeground:0",
  "visualRect": "385,945 140x36",
  "opaque": false
}
 has duplicated id with previous {
  "id": "0000015883F88EF0:DrawingPaintPhaseForeground:0",
  "visualRect": "140,993 161x46",
  "opaque": false
}
 (index=23)

Thank you for tracking this down. Duplicated id should be easier than deleted objects. Is it floating object?

This crash was introduced during M69 time frame, double digit instances as of now.

Manual regression finder
========================
https://crash.corp.google.com/browse?q=expanded_custom_data.ChromeCrashProto.ptype%3D%27renderer%27+AND+expanded_custom_data.ChromeCrashProto.magic_signature_1.name%3D%27blink%3A%3APaintController%3A%3AFinishCycle%27#-propertyselector,productname:1000,productversion:1000,-magicsignature:50,-magicsignature2:50,-stablesignature:50,-magicsignaturesorted:50

Possible suspect
=================
https://chromium.googlesource.com/chromium/src.git/+/d7209bb8a53bcc9636b2c12f18e7f7b74b0c02c8

Assigning to Xianzhu for further updates.Can we target for a fix in M71?

This is a bug of LayoutNG (which is under-development and not enabled yet), not a regression. The error occurs when LayoutNG paints two display items with the same ID.

I can't reproduce the issue, neither crash in FinishCycle nor duplicated id, with the reported URL with LayoutNG enabled.

Filed bug 906756 for crash in FinishCycle without LayoutNG. 

Still happening with LayoutNG in the latest canary, see
https://crash.corp.google.com/browse?q=product.name%3D%22Chrome%22%20AND%20product.version%3D%2273.0.3666.0%22%20AND%20custom_data.ChromeCrashProto.channel%20IN%20%28%22canary%22%29%20AND%20FORMAT_TIMESTAMP%28%22%25Y%25m%25d%22%2CTIMESTAMP_MICROS%28reporttime%2A1000%29%29%3D%2220190109%22%20AND%20custom_data.ChromeCrashProto.magic_signature_1.name%3D%22blink%3A%3APaintController%3A%3AFinishCycle%22%20AND%20EXISTS%28SELECT%201%20FROM%20UNNEST%28expanded_custom_data.ChromeCrashProto.experiments.ids%29%20expId%20WHERE%20expId%3D%226848cc95-3f4a17df%22%29

This looks like an under-invalidation of PaintLayer (missing SetNeedsRepaint) when some LayoutNG-specific DisplayItemClient is deleted. Hope someone familiar with LayoutNG can work on this.

According to discussion in slack/#layoutng, recreating NGPaintFragments without invalidating the painting layer may be the reason of the crash.

NGPaintFragment destructor might not be the best place for the invalidation because finding the painting layer is not super fast. The best place might be somewhere that we destroy a lot of NGPaintFragments at once.

Note that without reusing NGPaintFragments, the invalidation may make the performance regression worse.

From slack:
> crbug.com/906756 is the PaintController::FinishCycle() bug. It's still open. The cause is under-invalidation of cached subsequences (for stacking-context PaintLayer), that is, when some painting changed in some stacking-context, we missed setNeedsRepaint of the PaintLayer.

> For the bug, the change is specifically deletion of a DisplayItemClient. We need setNeedsRepaint of the painting layer when a DisplayItemClient is deleted. If NG has higher crash rate, there might be some NG-specific DisplayItemClient missing setNeedsRepaint of the painting layer

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

commit 22b59cde0c76db5687f51c3014661cdec7d14cc6
Author: Koji Ishii <kojii@chromium.org>
Date: Wed Jan 16 03:15:25 2019

[LayoutNG] Fix crash in PaintController::FinishCycle

According to wangxianzhu@, the crash is specifically about
a missing setNeedsRepaint of the painting layer when a
DispalyItemClient is missing.

This patch adds that, when the root NGPaintFragment of
inline formatting context (LayoutBlockFlow) is destroyed.

This is a speculative fix.

Bug:  866771 , 906756
Change-Id: I9a833671ef67079d06a96f42aa47a9d277d3b77c
Reviewed-on: https://chromium-review.googlesource.com/c/1410953
Commit-Queue: Koji Ishii <kojii@chromium.org>
Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#623078}
[modify] https://crrev.com/22b59cde0c76db5687f51c3014661cdec7d14cc6/third_party/blink/renderer/core/layout/ng/layout_ng_mixin.cc

No new crashers reported since 3674. Closing!