515811 - "ASSERTION: Some PresArena objects were not freed" with -moz-column, floats, huge font

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Jesse Ruderman]

Attachment: testcase (triggers assertion when closed)

###!!! ASSERTION: Some PresArena objects were not freed: 'mAllocCount == 0', file /Users/jruderman/central/layout/base/nsPresArena.cpp, line 169

Seems exploitable, but I'm not as sure as usual.

Comment 1

[Timothy Nikkel (:tnikkel)]

Attachment: patch

I knew I should have listened to that nagging voice saying "what about the other early exit in ReflowBlockFrame?" from bug 513394.

When reflowing (the first continuation of) the div that is the child of the <div style="float: left; -moz-column-count: 3;"> (the div for short) we call ReflowBlockFrame on the <div style="clear: both;"> and it returns early, without setting mPrevChild because of this code

  if (!treatWithClearance && !applyTopMargin && mightClearFloats &&
      aState.mReflowState.mDiscoveredClearance) {
    nscoord curY = aState.mY + aState.mPrevBottomMargin.get();
    nscoord clearY = aState.ClearFloats(curY, breakType, replacedBlock);
    if (clearY != curY) {
      // Looks like that assumption was invalid, we do need
      // clearance. Tell our ancestor so it can reflow again. It is
      // responsible for actually setting our clearance flag before
      // the next reflow.
      treatWithClearance = PR_TRUE;
      // Only record the first frame that requires clearance
      if (!*aState.mReflowState.mDiscoveredClearance) {
        *aState.mReflowState.mDiscoveredClearance = frame;
      }
      // Exactly what we do now is flexible since we'll definitely be
      // reflowed.
      return NS_OK;
    }
  }

And then back in ReflowDirtyLines after the main loop over the lines is finished we check if we should pull lines with

  PRBool heightConstrained =
    aState.mReflowState.availableHeight != NS_UNCONSTRAINEDSIZE;
  PRBool skipPull = willReflowAgain && heightConstrained;

except aState.mReflowState.availableHeight has overflowed and is now unconstrained. So we end up pulling frames and mPrevChild is one back of where is should be for the pull.

The available height gets set to unconstrained in ReflowBlockFrame where we ComputeCollapsedTopMargin, and the topMargin is unconstrained because the huge font on the child <div id="x" style="margin: 1em 0pt;"> gives a huge margin. And then we do

    // Now put the Y coordinate back to the top of the top-margin +
    // clearance, and flow the block.
    aState.mY -= topMargin;
    availSpace.y -= topMargin;
    if (NS_UNCONSTRAINEDSIZE != availSpace.height) {
      availSpace.height += topMargin;
    }

so the available height becomes unconstrained.

Comment 2

[fantasai]

Comment on attachment 400699 [details] [diff] [review]
patch

It looks reasonable to me, but I'd rather have dbaron, bz, or roc take a look here.

Comment 3

[Jesse Ruderman]

WFM?  I'm suspicious, though, because bug 497495 part 4 moved this assertion.

Comment 4

[Timothy Nikkel (:tnikkel)]

The moving of the assertion in bug 497495 isn't to blame as I still get the (moved) assertion in a debug build at http://hg.mozilla.org/mozilla-central/rev/c655e28003ef which is after that landed.

Comment 5

[Timothy Nikkel (:tnikkel)]

Oh, it's due to the landing of bug 512471. At the end of ReflowDirtyLines it no longer depends on mPrevChild being set correctly so it doesn't fail.

Comment 6

[Timothy Nikkel (:tnikkel)]

I think it's still worth it to do this patch though.

Comment 7

[Timothy Nikkel (:tnikkel)]

Oh, and bug 512471 is not going to land on branches, so we'll need this patch for branches.

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 400699 [details] [diff] [review]
patch

sr=dbaron, although I'm not sure why we're going on and pulling frames (and reflowing more frames?) after we've already discovered we need to reflow again

Comment 9

[Timothy Nikkel (:tnikkel)]

http://hg.mozilla.org/mozilla-central/rev/bb82129563af

Comment 10

[Daniel Veditz [:dveditz]]

Comment on attachment 400699 [details] [diff] [review]
patch

Approved for 1.9.1.6 and 1.9.0.16, a=dveditz for release-drivers

Comment 11

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Comment on attachment 400699 [details] [diff] [review]
patch

a=shaver for 1.9.2, thanks again timothy!

Comment 12

[Timothy Nikkel (:tnikkel)]

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/e0529f8ec04e

Comment 13

[Timothy Nikkel (:tnikkel)]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/49e937c4a4db

Comment 14

[Boris Zbarsky [:bzbarsky]]

Checking in nsBlockFrame.cpp;
/cvsroot/mozilla/layout/generic/nsBlockFrame.cpp,v  <--  nsBlockFrame.cpp
new revision: 3.967; previous revision: 3.966

Comment 15

[Al Billings [:abillings - ex-MoCo]]

With debug 1.9.1 from before the fix, I don't see the assertion in comment 0. 
The only assert that I see that seems related, perhaps, is: 

###!!! ASSERTION: Some objects allocated with AllocateFrame were not freed: 'mFrameCount == 0', file /Users/albill/mozilla-191/layout/base/nsPresShell.cpp, line 674

With debug 1.9.0 before the fix, I see no assertion at all.

Is this just a defense in depth fix on 1.9.1 and 1.9.0 or were these assertions actually seen on these two branches?

Comment 16

[Jesse Ruderman]

That's the same assertion.  Its text changed at some point.

Comment 17

[Al Billings [:abillings - ex-MoCo]]

All right, so it is definitely fixed for 1.9.1. 

I don't see any assertion during 1.9.0 runs before the fix.

Comment 18

[Timothy Nikkel (:tnikkel)]

Added crashtest to 1.9.1, 1.9.2, and mozilla-central.
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/976ec8c4d911
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/914ae05fe0a2
http://hg.mozilla.org/mozilla-central/rev/260d768e55f4