Closed Bug 799207 Opened 7 years ago Closed 7 years ago

Assertion failure: "using uninitialized baseline offset" with flexbox

Categories

(Core :: Layout, defect, critical)

defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla19

People

(Reporter: jruderman, Assigned: dholbert)

References

(Blocks 1 open bug)

Details

(Keywords: assertion, testcase)

Attachments

(3 files, 1 obsolete file)

Attached file testcase
With
  user_pref("layout.css.flexbox.enabled", true);
the testcase triggers:

Assertion failure: mCrossStartToFurthestBaseline != (-nscoord(1 << 30)) (using uninitialized baseline offset), at layout/generic/nsFlexContainerFrame.cpp:1659
Attached file stack trace
/me starts writing on chalkboard:
> I will not write fatal assertions that assume reasonably-sized content.
> I will not write fatal assertions that assume reasonably-sized content.
> [etc]
Assignee: nobody → dholbert
Status: NEW → ASSIGNED
Attached patch fix (obsolete) — Splinter Review
So -- our "mCrossStartToFurthestBaseline"-determination code starts out at negative infinity (nscoord_MIN), and then assumes that any baseline-aligned content will bring it up to a larger value, with a series of these for each baseline-aligned flex item:
>     mCrossStartToFurthestBaseline = NS_MAX(mCrossStartToFurthestBaseline,
>                                            crossStartToBaseline);

In this case, "crossStartToBaseline" is _more negative_ than nscoord_MIN (since nscoord_MIN isn't strictly the lowest representable nscoord value).  So we leave mCrossStartToFurthestBaseline at its initial value (representing "negative infinity").

I think it's fine to just warn in this case.  We could sprinkle some nscoord-saturating addition around, too, but I don't think it'd really help, since we'd still end up with nscoord_MIN.
Attachment #669318 - Flags: review?(dbaron)
Comment on attachment 669318 [details] [diff] [review]
fix

Sorry, I had two debugging sessions mixed up.  I thought we were dealing with gigantic negative values, but we're actually dealing with gigantic positive values, which when added together, wrap into negative territory (to a value below nscoord_MIN).

So -- we do need to reduce the severity of the assertion, because we could legitimately get values as low as nscoord_MIN. But we also probably want some saturating addition to keep us from wrapping around from positive to negative.
Attachment #669318 - Flags: review?(dbaron)
Attached patch fix v2Splinter Review
OK, so this fix has a saturating-addition tweak, to keep us from overflowing into negative territory from adding an nscoord_MAX margin-top to an nscoord_MAX ascent.

With that, Jesse's testcase no longer triggers the assertion, so I added another crashtest that *does* still trigger it (with a giant negative margin-top), to justify still reducing the severity.
Attachment #669318 - Attachment is obsolete: true
Attachment #669345 - Flags: review?(dbaron)
(FWIW, the "asserts(12)" annotation on the new crashtest is for a bunch of
  "ASSERTION: nscoord addition will reach or pass nscoord_MIN"
  "ASSERTION: NSCoordSaturatingAdd got nscoord_MIN as argument"
type assertions, for adding our margin-top (nscoord_MIN) to our ascent (0).)
Depends on: css3-flexbox
Comment on attachment 669345 [details] [diff] [review]
fix v2

r=dbaron
Attachment #669345 - Flags: review?(dbaron) → review+
OS: Mac OS X → All
Hardware: x86_64 → All
Unprefixed testcase (per bug 801098), and pushed:
https://hg.mozilla.org/integration/mozilla-inbound/rev/16adea14324f
Flags: in-testsuite+
https://hg.mozilla.org/mozilla-central/rev/16adea14324f
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla19
You need to log in before you can comment on or make changes to this bug.