From findit tool:

Author: pdr
Project: chromium
Changelist: https://chromium.googlesource.com/chromium/src//+/6c961fe1112914b9d63d6551e31b96c415dfb83f
Time: Tue Apr 26 03:17:41 2016
The CL last changed line 1002 of file LayoutBlockFlow.cpp, which is stack frame 2.

I think this was https://chromium.googlesource.com/chromium/src/+/43862543cb7622a39c6fbc7895ffe03ba5337f54 which added the assert.

@mstensho, could you take a look? I minimized the crash a little bit to make it easier.

Deleted: crash.html 948 bytes

crash.html 948 bytes View Download

Thanks for the reduction, pdr!

Further reduction attached.

ASSERTION FAILED: createsNewFormattingContext()
../../third_party/WebKit/Source/core/layout/LayoutBlockFlow.cpp(313) : virtual bool blink::LayoutBlockFlow::isSelfCollapsingBlock() const

#0  0x0000000003e16390 in blink::LayoutBlockFlow::isSelfCollapsingBlock (this=0x53c51024240) at ../../third_party/WebKit/Source/core/layout/LayoutBlockFlow.cpp:313
#1  0x0000000003e1b1ed in blink::LayoutBlockFlow::rebuildFloatsFromIntruding (this=0x53c51024470) at ../../third_party/WebKit/Source/core/layout/LayoutBlockFlow.cpp:1073
#2  0x0000000003e27c1c in blink::LayoutBlockFlow::layoutBlockFlow (this=0x53c51024470, relayoutChildren=false, pageLogicalHeight=0px, layoutScope=...) at ../../third_party/WebKit/Source/core/layout/LayoutBlockFlow.cpp:429
#3  0x0000000003e169b3 in blink::LayoutBlockFlow::layoutBlock (this=0x53c51024470, relayoutChildren=false) at ../../third_party/WebKit/Source/core/layout/LayoutBlockFlow.cpp:395
#4  0x0000000003e013d0 in blink::LayoutBlock::layout (this=0x53c51024470) at ../../third_party/WebKit/Source/core/layout/LayoutBlock.cpp:433
#5  0x0000000003e09e46 in blink::LayoutObject::layoutIfNeeded (this=0x53c51024470) at ../../third_party/WebKit/Source/core/layout/LayoutObject.h:905
#6  0x0000000003ed39e2 in blink::LayoutMultiColumnSpannerPlaceholder::layout (this=0x53c5104c010) at ../../third_party/WebKit/Source/core/layout/LayoutMultiColumnSpannerPlaceholder.cpp:107
#7  0x00000000039b75d9 in blink::FrameView::layoutOrthogonalWritingModeRoots (this=0x162f9c242d48) at ../../third_party/WebKit/Source/core/frame/FrameView.cpp:1783
#8  0x00000000039b708f in blink::FrameView::performLayout (this=0x162f9c242d48, inSubtreeLayout=false) at ../../third_party/WebKit/Source/core/frame/FrameView.cpp:872
#9  0x00000000039b8412 in blink::FrameView::layout (this=0x162f9c242d48) at ../../third_party/WebKit/Source/core/frame/FrameView.cpp:1039

LayoutView 0x7a87f404010               	#document	0x3508a4922490
  LayoutBlockFlow 0x7a87f424010        	HTML	0x3508a4923018
    LayoutBlockFlow 0x7a87f424128      	BODY	0x3508a49230e8
      LayoutBlockFlow 0x7a87f424240    	P	0x3508a4923150
        LayoutText 0x7a87f42c010       	#text	0x3508a49231b8 "PASS if no crash or assertion failure."
      LayoutBlockFlow 0x7a87f424358    	DIV	0x3508a4923258 ID="mc" STYLE="columns: auto 3; width: 100px; writing-mode: tb-rl;"
        LayoutMultiColumnFlowThread (anonymous) 0x7a87f434010
*         LayoutBlockFlow (anonymous) 0x7a87f424588
            LayoutText 0x7a87f42c0b8   	#text	0x3508a49232c0 "\n    abc\n    "
          LayoutBlockFlow (column spanner) 0x7a87f424470	DIV	0x3508a4923310 ID="spanner" STYLE="height: 100px; column-span: all; margin-left: 1px;"
        LayoutMultiColumnSet (anonymous) 0x7a87f444010
        LayoutMultiColumnSpannerPlaceholder (anonymous) 0x7a87f44c010

So the fact that the spanner establishes an orthogonal writing mode root makes us jump directly to that one and lay it out before laying out the rest (including preceding content). The anonymous block that precedes the spanner hasn't been laid out yet, and the margin collapsing machinery starts walking backwards from the spanner, and encounters this anonymous block that hasn't yet been laid out. This is bad. It should be fairly easy to come up with a fix for the test case, since it's just nonsense to attempt to collapse the spanner with anything. 

But I wonder if this is a more generic issue, that doesn't have to involve multicol.

Deleted: tc.html 367 bytes

tc.html 367 bytes View Download

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

commit 88b19ef7788c9b388cf5eb877d75c264d81e4298
Author: mstensho <mstensho@opera.com>
Date: Fri May 20 17:31:01 2016

Keep writing-mode in sync between a column spanner and its placeholder.

Don't exclude LayoutMultiColumnSpannerPlaceholder (which is just a LayoutBox)
in propagateStyleToAnonymousChildren(). There was an optional requirement for
the child to be LayoutBlock or better, but there really doesn't seem to be
any point in doing this. We no longer create anonymous LayoutInline objects,
ever, anyway (will file a separate CL to remove some unneeded support code
for that in LayoutInline).

All we need to do now is to steer clear of such anonymous objects that have
custom ways of inheriting style. LayoutFullScreen and
LayoutFullScreenPlaceholder were already taken care of. Now that we always
try to propagate style to non-LayoutBlock objects as well, we need to avoid
LayoutListMarker too.

BUG= 608123 

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

[add] https://crrev.com/88b19ef7788c9b388cf5eb877d75c264d81e4298/third_party/WebKit/LayoutTests/fast/multicol/span/change-multicol-writing-mode-expected.html
[add] https://crrev.com/88b19ef7788c9b388cf5eb877d75c264d81e4298/third_party/WebKit/LayoutTests/fast/multicol/span/change-multicol-writing-mode.html
[modify] https://crrev.com/88b19ef7788c9b388cf5eb877d75c264d81e4298/third_party/WebKit/Source/core/layout/LayoutBlock.cpp
[modify] https://crrev.com/88b19ef7788c9b388cf5eb877d75c264d81e4298/third_party/WebKit/Source/core/layout/LayoutFullScreen.cpp
[modify] https://crrev.com/88b19ef7788c9b388cf5eb877d75c264d81e4298/third_party/WebKit/Source/core/layout/LayoutFullScreen.h
[modify] https://crrev.com/88b19ef7788c9b388cf5eb877d75c264d81e4298/third_party/WebKit/Source/core/layout/LayoutInline.cpp
[modify] https://crrev.com/88b19ef7788c9b388cf5eb877d75c264d81e4298/third_party/WebKit/Source/core/layout/LayoutListMarker.h
[modify] https://crrev.com/88b19ef7788c9b388cf5eb877d75c264d81e4298/third_party/WebKit/Source/core/layout/LayoutObject.cpp
[modify] https://crrev.com/88b19ef7788c9b388cf5eb877d75c264d81e4298/third_party/WebKit/Source/core/layout/LayoutObject.h
[modify] https://crrev.com/88b19ef7788c9b388cf5eb877d75c264d81e4298/third_party/WebKit/Source/core/layout/LayoutTable.cpp

(so I realized that this required a spanner to reproduce, and that the issue doesn't exist outside of multicol, as I first feared)

Removing EditIssue view restrictions from ClusterFuzz filed bugs. If you believe that this issue should still be restricted, please reapply the label.

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