Closed Bug 1349650 Opened 6 years ago Closed 6 years ago

[css-grid] Assertion failure: mIter.isSome() || mArray->Length() == aGridItemCount (grid item count mismatch)


(Core :: Layout, defect, P2)

52 Branch



Tracking Status
firefox52 --- wontfix
firefox-esr52 --- wontfix
firefox53 --- fixed
firefox54 --- fixed
firefox55 --- fixed


(Reporter: truber, Assigned: MatsPalmgren_bugz)



(Keywords: assertion, testcase)


(3 files)

Attached file testcase.html
The attached testcase asserts in mozilla-central rev e03e0c60462.

Assertion failure: mIter.isSome() || mArray->Length() == aGridItemCount (grid item count mismatch), at /home/worker/workspace/build/src/layout/generic/nsGridContainerFrame.cpp:474
#01: nsGridContainerFrame::Reflow at layout/generic/nsGridContainerFrame.cpp:6196
#02: nsBlockReflowContext::ReflowBlock at layout/generic/nsBlockReflowContext.cpp:307
#03: nsBlockFrame::ReflowBlockFrame at layout/generic/nsBlockFrame.cpp:3470
#04: nsBlockFrame::ReflowLine at layout/generic/nsBlockFrame.cpp:2831
#05: nsBlockFrame::ReflowDirtyLines at layout/generic/nsBlockFrame.cpp:2370
#06: nsBlockFrame::Reflow at layout/generic/nsBlockFrame.cpp:1250
#07: nsContainerFrame::ReflowChild at layout/generic/nsContainerFrame.cpp:900
#08: nsCanvasFrame::Reflow at layout/generic/nsCanvasFrame.cpp:722
#09: nsContainerFrame::ReflowChild at layout/generic/nsContainerFrame.cpp:900
#10: nsHTMLScrollFrame::ReflowScrolledFrame at layout/generic/nsGfxScrollFrame.cpp:556
#11: nsHTMLScrollFrame::ReflowContents at layout/generic/nsGfxScrollFrame.cpp:686
#12: nsHTMLScrollFrame::Reflow at layout/generic/nsGfxScrollFrame.cpp:1041
#13: nsContainerFrame::ReflowChild at layout/generic/nsContainerFrame.cpp:943
#14: mozilla::ViewportFrame::Reflow at layout/generic/ViewportFrame.cpp:330
#15: mozilla::PresShell::DoReflow at layout/generic/ReflowOutput.h:282
Flags: in-testsuite?
Assignee: nobody → mats
OS: Unspecified → All
Priority: -- → P2
Hardware: Unspecified → All
Summary: Assertion failure: mIter.isSome() || mArray->Length() == aGridItemCount (grid item count mismatch) → [css-grid] Assertion failure: mIter.isSome() || mArray->Length() == aGridItemCount (grid item count mismatch)
I can't reproduce the bug in a Linux64 debug build from the exact same rev
as yours (which is currently m-c tip), using a fresh profile.
Daniel, can you reproduce this assertion?
Flags: needinfo?(dholbert)
Sorry, my clownshoes are showing -- I forgot that the build I tested in had "--disable-debug" in its mozconfig, so of course assertions were disabled.

I can reproduce this in a Linux64 debug build that I just downloaded from treeherder -- the "target.tar.bz2" tarball here:

(Direct link: )

Mats, if your tested local build is definitely a debug build & you still can't reproduce, maybe try that ^^ tarball as an extra sanity check?
Flags: needinfo?(jschwartzentruber) → needinfo?(mats)
Ah, the plot thickens -- my *locally-built* enable-debug/disable-optimize build does not reproduce the issue.

The main distinction between my just-tested local build & the downloaded tarball from comment 4 is "disable-optimize" (local bulid) vs "enable-optimize" (treeherder build -- technically unspecified, but this is the default).

So maybe this depends on some subtly-different initialization / out-of-order instructions that only happen in enable-optimize builds...?
Thanks Daniel, I indeed have disable-optimize in my .mozconfig.
I'll rebuild with enable-optimize and see if that helps.
Flags: needinfo?(mats)
Thanks Daniel. I only try taskcluster builds usually (mozilla-central.latest.firefox.linux64-debug). I didn't realize those are optimized.
Nope, that build didn't reproduce it either.  Hmm, it might be a gcc/clang difference...
Yep, now I can reproduce it.  gcc + enable-optimize did it.
Attached patch fixSplinter Review
It's just a bogus assertion.
When mArray is used it contains all grid container children, including
placeholders.  aGridItemCount always excludes placeholders.
Attachment #8850517 - Flags: review?(dholbert)
Attached patch crashtestSplinter Review
(BTW, I'm amazed how much faster enable-optimize makes the build, even with enable-debug.
It feels like an order of magnitude or so.  It does make it less debuggable though,
with gdb frequently displaying <optimized out> when trying to print variables.
It seems worth investigating if adding -Og and/or -ggdb helps with that though...)
(In reply to Mats Palmgren (:mats) from comment #9)
> Yep, now I can reproduce it.  gcc + enable-optimize did it.

Glad to hear it. I can't reproduce with *clang* + enable-optimize, FWIW. (I left that building overnight to test in the morning, & just tried it.  But I guess that's just because clang & gcc perform different optimizations.
D'oh, I just now noticed the "CLANG_CRASH_BUG" exclusion-ifdef around the condition -- that definitely explains why I'm not hitting it. :)  (I'm using clang 3.8.1 on this machine, which satisfies the CLANG_CRASH_BUG condition.)
Comment on attachment 8850517 [details] [diff] [review]

Review of attachment 8850517 [details] [diff] [review]:

Attachment #8850517 - Flags: review?(dholbert) → review+
Flags: in-testsuite? → in-testsuite+
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
I'm going to assume that this isn't worth backporting. Feel free to set things back to affected and make the requests if you feel otherwise, though.
Blocks: 1151204
Version: Trunk → 52 Branch
I agree. It's a debug-only change, so there's no user benefit that we'd gain from uplifting this.
...though actually, this is in a piece of code that I want to move around over in Bug 812687 (and I'll want to uplift the patches over there).

So it would make for an easier/cleaner uplift over there, if we uplifted this bug's patches over here.

I think we don't need to bother with uplift approval over here, though -- this bug only changes the inside of a MOZ_ASSERT expression, so it's debug-only and hence NPOTB.
You need to log in before you can comment on or make changes to this bug.