1335552 - Assertion failure: !aWM.IsOrthogonalTo(GetWritingMode()), at /home/worker/workspace/build/src/layout/generic/nsIFrameInlines.h:134

Status: RESOLVED FIXED

(Core :: Layout, defect, P3)

Description

[Tyson Smith [:tsmith]]

Attachment: log.txt

Assertion failure: !aWM.IsOrthogonalTo(GetWritingMode()), at /home/worker/workspace/build/src/layout/generic/nsIFrameInlines.h:134

==12281==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f512169059e bp 0x7ffdb5700c90 sp 0x7ffdb5700be0 T0)
    #0 0x7f512169059d in nsIFrame::SynthesizeBaselineBOffsetFromBorderBox(mozilla::WritingMode, mozilla::BaselineSharingGroup) const /home/worker/workspace/build/src/layout/generic/nsIFrameInlines.h:140:3
    #1 0x7f512168fc55 in nsLayoutUtils::GetFirstLinePosition(mozilla::WritingMode, nsIFrame const*, nsLayoutUtils::LinePosition*) /home/worker/workspace/build/src/layout/base/nsLayoutUtils.cpp:5912:30
    #2 0x7f512168f8b9 in nsLayoutUtils::GetFirstLinePosition(mozilla::WritingMode, nsIFrame const*, nsLayoutUtils::LinePosition*) /home/worker/workspace/build/src/layout/base/nsLayoutUtils.cpp:5966:11
    #3 0x7f512168f63e in nsLayoutUtils::GetFirstLineBaseline(mozilla::WritingMode, nsIFrame const*, int*) /home/worker/workspace/build/src/layout/base/nsLayoutUtils.cpp:5885:8
    #4 0x7f51219a6509 in nsTableCellFrame::GetCellBaseline() const /home/worker/workspace/build/src/layout/tables/nsTableCellFrame.cpp:730:7
    #5 0x7f51219e7adb in nsTableRowFrame::ReflowChildren(nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, nsTableFrame&, unsigned int&) /home/worker/workspace/build/src/layout/tables/nsTableRowFrame.cpp:971:20
    #6 0x7f51219ea4a0 in nsTableRowFrame::Reflow(nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, unsigned int&) /home/worker/workspace/build/src/layout/tables/nsTableRowFrame.cpp:1119:3
    #7 0x7f5121788f4e in nsContainerFrame::ReflowChild(nsIFrame*, nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, mozilla::WritingMode const&, mozilla::LogicalPoint const&, nsSize const&, unsigned int, unsigned int&, nsOverflowContinuationTracker*) /home/worker/workspace/build/src/layout/generic/nsContainerFrame.cpp:1028:3
    #8 0x7f51219ef47b in nsTableRowGroupFrame::ReflowChildren(nsPresContext*, mozilla::ReflowOutput&, mozilla::TableRowGroupReflowInput&, unsigned int&, bool*) /home/worker/workspace/build/src/layout/tables/nsTableRowGroupFrame.cpp:432:7
    #9 0x7f51219f6405 in nsTableRowGroupFrame::Reflow(nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, unsigned int&) /home/worker/workspace/build/src/layout/tables/nsTableRowGroupFrame.cpp:1387:3
    #10 0x7f5121788f4e in nsContainerFrame::ReflowChild(nsIFrame*, nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, mozilla::WritingMode const&, mozilla::LogicalPoint const&, nsSize const&, unsigned int, unsigned int&, nsOverflowContinuationTracker*) /home/worker/workspace/build/src/layout/generic/nsContainerFrame.cpp:1028:3
    #11 0x7f51219c0979 in nsTableFrame::ReflowChildren(mozilla::TableReflowInput&, unsigned int&, nsIFrame*&, nsOverflowAreas&) /home/worker/workspace/build/src/layout/tables/nsTableFrame.cpp:3153:7
    #12 0x7f51219bdc18 in nsTableFrame::ReflowTable(mozilla::ReflowOutput&, mozilla::ReflowInput const&, int, nsIFrame*&, unsigned int&) /home/worker/workspace/build/src/layout/tables/nsTableFrame.cpp:2118:3
    #13 0x7f51219bcad5 in nsTableFrame::Reflow(nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, unsigned int&) /home/worker/workspace/build/src/layout/tables/nsTableFrame.cpp:1918:5
    #14 0x7f5121788f4e in nsContainerFrame::ReflowChild(nsIFrame*, nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, mozilla::WritingMode const&, mozilla::LogicalPoint const&, nsSize const&, unsigned int, unsigned int&, nsOverflowContinuationTracker*) /home/worker/workspace/build/src/layout/generic/nsContainerFrame.cpp:1028:3
    #15 0x7f51219ffc26 in nsTableWrapperFrame::OuterDoReflowChild(nsPresContext*, nsIFrame*, mozilla::ReflowInput const&, mozilla::ReflowOutput&, unsigned int&) /home/worker/workspace/build/src/layout/tables/nsTableWrapperFrame.cpp:832:3
    #16 0x7f5121a010ca in nsTableWrapperFrame::Reflow(nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, unsigned int&) /home/worker/workspace/build/src/layout/tables/nsTableWrapperFrame.cpp:994:3
    #17 0x7f512175fa7a in nsBlockReflowContext::ReflowBlock(mozilla::LogicalRect const&, bool, nsCollapsingMargin&, int, bool, nsLineBox*, mozilla::ReflowInput&, unsigned int&, mozilla::BlockReflowInput&) /home/worker/workspace/build/src/layout/generic/nsBlockReflowContext.cpp:306:3
    #18 0x7f5121758228 in nsBlockFrame::ReflowBlockFrame(mozilla::BlockReflowInput&, nsLineList_iterator, bool*) /home/worker/workspace/build/src/layout/generic/nsBlockFrame.cpp:3466:7
    #19 0x7f5121754468 in nsBlockFrame::ReflowLine(mozilla::BlockReflowInput&, nsLineList_iterator, bool*) /home/worker/workspace/build/src/layout/generic/nsBlockFrame.cpp:2835:5
    #20 0x7f512174abc7 in nsBlockFrame::ReflowDirtyLines(mozilla::BlockReflowInput&) /home/worker/workspace/build/src/layout/generic/nsBlockFrame.cpp:2374:7
    #21 0x7f51217459d3 in nsBlockFrame::Reflow(nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, unsigned int&) /home/worker/workspace/build/src/layout/generic/nsBlockFrame.cpp:1237:3
    #22 0x7f512175fa7a in nsBlockReflowContext::ReflowBlock(mozilla::LogicalRect const&, bool, nsCollapsingMargin&, int, bool, nsLineBox*, mozilla::ReflowInput&, unsigned int&, mozilla::BlockReflowInput&) /home/worker/workspace/build/src/layout/generic/nsBlockReflowContext.cpp:306:3
...
see log.txt

Comment 1

[Tyson Smith [:tsmith]]

Attachment: test_case.html

Comment 2

[Ryan VanderMeulen [:RyanVM]]

INFO: Last good revision: da6f3eb57c7800df35868f3a52bb04a0caccf97e
INFO: First bad revision: efcaf80ef8590b3dc41b75e836cd13f308a413a1
INFO: Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=da6f3eb57c7800df35868f3a52bb04a0caccf97e&tochange=efcaf80ef8590b3dc41b75e836cd13f308a413a1

Comment 3

[Tyson Smith [:tsmith]]

Hoping to help get this fixed since fuzzers have been tripping over it for a few years now.

Here is a Pernosco session https://pernos.co/debug/OJwdaV_sBxF7lEBXHxWw6g/index.html

Comment 4

[Tyson Smith [:tsmith]]

Mats, do you have any time to have a look? or is there anything else I can do to help?

Comment 5

[Tyson Smith [:tsmith]]

This issues has been open for a long time and the fuzzers frequently trip over it. If this is benign can this be downgraded to a warning?

Sean is there someone that could have a look at this?

Comment 6

[Sean Voisen (:svoisen)]

I'll keep the ni? open on Mats. He's currently on PTO.

In the interim, Jonathan is this something you can look into?

Comment 7

[Jonathan Kew [:jfkthame]]

At the time we hit this assertion, we have a frame tree that looks like this:

Block(body)(2)@14e876b88 parent=14e876ac0 (0,0,0,0) [state=0002020000100603] [content=14d302430] [cs=14e802898]<
  line 14e877840: count=1 state=block,clean,prevmarginclean,not-impacted,not-wrapped,before:nobr,after:nobr[0x8] (0,0,0,0) <
    TableWrapper(body)(2)@14e876ea0 parent=14e876b88 (0,0,0,0) [state=0002000000000603] [content=14d302430] [cs=14ad225c8:-moz-table-wrapper]<
      Table(body)(2)@14e876f50 parent=14e876ea0 (0,0,0,0) [state=008b000000000403] [content=14d302430] [cs=14ad22208:-moz-table]<
        TableRowGroup(tbody)(1)@14e877080 parent=14e876f50 (0,0,0,0) [state=000b020000000403] [content=14d3028b0] [cs=14ad22118]<
          TableRow(tbody)(1)@14e877130 parent=14e877080 (0,0,0,0) [state=000b000000000403] [content=14d3028b0] [cs=14ad22c58:-moz-table-row]<
            TableCell(tbody)(1)@14e8771f8 parent=14e877130 (0,0,0,0) [state=008b000000000403] [content=14d3028b0] [cs=14ad226b8:-moz-table-cell]<
              Block(tbody)(1)@14e8772c0 parent=14e8771f8 (0,0,0,0) wm=sw-lr-ltr logical-size=(0 x 0) [state=000b000008d00000] [content=14d3028b0] [cs=14ad23018:-moz-cell-content]<
                line 14e876c50: count=1 state=block,clean,prevmarginclean,not-impacted,not-wrapped,before:nobr,after:nobr[0x108] (0,0,0,0) wm=sw-lr-ltr cs=(0 x 0) logical-rect=(0,0,0,0) <
                  TableWrapper(tbody)(1)@14e877388 parent=14e8772c0 (0,0,0,0) wm=sw-lr-ltr logical-size=(0 x 0) parent-wm=sw-lr-ltr cs=(0 x 0) logical-rect=(0,0,0,0) [state=000b000000000200] [content=14d3028b0] [cs=14ad227a8:-moz-table-wrapper]<
                    Table(tbody)(1)@14e877438 parent=14e877388 (0,0,0,0) wm=sw-lr-ltr logical-size=(0 x 0) parent-wm=sw-lr-ltr cs=(0 x 0) logical-rect=(0,0,0,0) [state=008b000000000000] [content=14d3028b0] [cs=14ad222f8:-moz-table]
                    ColGroupList 14e877558 <
                      TableColGroup(tbody)(1)@14e877568 parent=14e877438 (0,0,0,0) wm=sw-lr-ltr logical-size=(0 x 0) parent-wm=sw-lr-ltr cs=(0 x 0) logical-rect=(0,0,0,0) [state=000b000000000000] [content=14d3028b0] [cs=14ad232e8:-moz-table-column-group]<
                        TableCol(col)(0)@14e877618 parent=14e877568 (0,0,0,0) wm=sw-lr-ltr logical-size=(0 x 0) parent-wm=sw-lr-ltr cs=(0 x 0) logical-rect=(0,0,0,0) [state=0009020000000000] [content=14d302940] [cs=14ad22e38]
                      >
                    >
                  >
                >
              >
            >
          >
        >
      >
      ColGroupList 14e877070 <
        TableColGroup(body)(2)@14e8776d8 parent=14e876f50 (0,0,0,0) [state=000b000040000000] [content=14d302430] [cs=14ad232e8:-moz-table-column-group]<
          TableCol(body)(2)@14e877788 parent=14e8776d8 (0,0,0,0) [state=0009000030000000] [content=14d302430] [cs=14ad235b8:-moz-table-column]
        >
      >
    >
  >
>

We normally force the frames for structural parts of a table (rowGroups, rows, etc -- though not cells IIRC) to use the parent <table>'s writing mode; it wouldn't make any sense to mix rows or columns with different writing modes within a single table. But the <tbody> generates an nsBlockFrame that doesn't have this behavior, so it picks up the orthogonal writing mode given in the CSS, and that breaks our assumptions about synthesizing baselines.

The <thead> or <tfoot> elements could run into the same issue.

We could try to make SynthesizeBaselineBOffsetFromBorderBox do something sensible in the orthogonal case, but I think a better solution is to ensure that the block and table frames associated with these table-section elements use the same writing-mode as the parent table, as it doesn't really make any sense for them to differ.

Comment 8

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1335552 - Force table section frames to share the writing mode of their parent table. r=dholbert

Comment 9

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1335552 - Make nsIFrame::SynthesizeBaselineBOffsetFromBorderBox do something reasonable with orthogonal writing modes. r=dholbert

Comment 10

[Jonathan Kew [:jfkthame]]

Note that there are other SynthesizeBaseline... methods that have similar assertions in them, and perhaps should be adapted to handle orthogonal modes in a similar way. But for the time being I'm inclined to only do this one (which is the simplest case); we can consider what to do in its sibling methods if the fuzzers ever find a way to hit them.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/61d0aecaf811
Make nsIFrame::SynthesizeBaselineBOffsetFromBorderBox do something reasonable with orthogonal writing modes. r=dholbert

Comment 12

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/61d0aecaf811

Comment 13

[Tyson Smith [:tsmith]]

Thank you! Fixing fuzz blockers is very much appreciated by the fuzzing team.