470167 - "ASSERTION: Should be in an update while creating frames" with stylesheet appended many times

Status: VERIFIED FIXED

(Core :: Layout, defect, P2)

Description

[Jesse Ruderman]

Attachment: testcase

This testcase triggers:

###!!! ASSERTION: Should be in an update while creating frames: 'mUpdateCount != 0', file layout/base/nsCSSFrameConstructor.cpp, line 8355

A related testcase (not attached) triggers:

###!!! ASSERTION: Should be in an update while destroying frames: 'mUpdateCount != 0', file layout/base/nsCSSFrameConstructor.cpp, line 9319

###!!! ASSERTION: Odd update count: 'mUpdateCount == 1', file layout/base/nsCSSFrameConstructor.cpp, line 10144

Bug 464863 also triggers the "should be in an update" assertions, but its testcase is very different.

Comment 1

[Jesse Ruderman]

Attachment: stack trace

Comment 2

[Boris Zbarsky [:bzbarsky]]

Whoops.  This is a regression from bug 431082.  The --mUpdateCount disappeared from nsCSSFrameConstructor::EndUpdate, so we overflow the counter.

Need to fix this.  smaug, want to patch?

Comment 3

[Olli Pettay [:smaug][[e-mail]](vacation until Nov 16)]

Ugh, yes. Idiot me.

Comment 4

[Olli Pettay [:smaug][[e-mail]](vacation until Nov 16)]

Attachment: put back --mUpdateCount

Comment 5

[Jesse Ruderman]

It's unfortunate that I had to overflow the counter to notice the bug.  Are there points at which we can assert that the counter is 0, perhaps when the object that owns the counter is destroyed?

Comment 6

[Boris Zbarsky [:bzbarsky]]

Hmm.  Yeah, I think it should be reasonable to have such an assert in ~nsCSSFrameConstructor.

Pushed http://hg.mozilla.org/mozilla-central/rev/018f2e97dedd to do that.

Comment 7

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 353893 [details] [diff] [review]
put back --mUpdateCount

a191=beltzner

Comment 8

[Jesse Ruderman]

in-testsuite- (the testcase in comment 0 is slow, and the assertion added in comment 6 covers the bug better the testcase does).

Comment 9

[Aakash Desai [:aakashd]]

pushed to 1.9.1 too: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/fcfcf03ce04d

verified FIXED (no assertions) using the attached test case on debug builds:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090608 Shiretoko/3.5pre ID:20090608122057

and

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090608 Minefield/3.6a1pre ID:20090608122028