Bugzilla@Mozilla – Bug 422301
Crash [@ nsOverflowContinuationTracker::Insert] with -moz-column, padding, margin
Last modified: 2009-02-03 18:49:13 PST
Summon comment box
Created attachment 308786 [details] testcase (crashes Firefox when loaded) Loading the testcase makes Firefox crash with nsOverflowContinuationTracker::Insert calling 0xdddddddd.
Created attachment 319135 [details] [review] hack What happens here is that at http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/layout/generic/nsBlockReflowContext.cpp&rev=1.157&mark=353-355#338 we delete the nextinflows of mFrame. If there is only one nextinflow thats fine. However if there are more of them and on of the nextinflows is tracked inside the overflowtracker we hold a pointer to a deleted entry in mSentry in the overflow. From the variable description of mSentry (http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/layout/generic/nsContainerFrame.h&rev=3.83&mark=548-551#545), this seems not like a very descriptive name to me, it is not clear to that mSentry has to be a primary frame and not on the frames overflows list. So the hack might be the correct thing to do.
I think the loop should be inside nsOverflowContinuationTracker::Finish.
Bernd asked me to take this.
I'm rolling this patch into bug 422283.
Fixed by checkin for 422283.
"blocking" so we remember to verify when we land bug 422283 on the branch
bug 422283 was checked into the 1.9.0 branch, we can verify this one now.
doesnt crash 1.8.1 here. and code from 422283 suggests that this is 1.9 and above only.
Verified fixed in 1.9.0.6 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.6pre) Gecko/2009011304 GranParadiso/3.0.6pre. Crash no longer repros as it does in 1.9.0.5.
Verified fix on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090130 Shiretoko/3.1b3pre Ubiquity/0.1.5 and Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090130 Minefield/3.2a1pre