Last Comment Bug 422301 - Crash [@ nsOverflowContinuationTracker::Insert] with -moz-column, padding, margin
: Crash [@ nsOverflowContinuationTracker::Insert] with -moz-column, padding, ma...
Status: VERIFIED FIXED
: [sg:critical][fixed for 1.9.0 in bug ...
: crash, testcase, verified1.9.0.6, verified1.9.1
Product: Core
Classification: Components
Component: Layout
: Trunk
: x86 Mac OS X
: -- critical (vote)
: ---
Assigned To: fantasai
: layout
:
: 422283
: 306939
  Show dependency treegraph
 
Reported: 2008-03-11 19:26 PDT by Jesse Ruderman
Modified: 2009-02-03 18:49 PST (History)
12 users (show)
roc: blocking1.9.1+
roc: blocking1.9-
dveditz: blocking1.9.0.6+
roc: wanted1.9.0.x+
asac: wanted1.8.1.x-
asac: wanted1.8.0.x-
roc: in‑testsuite+
See Also:
Crash Signature:
[@ nsOverflowContinuationTracker::Insert]


Attachments
testcase (crashes Firefox when loaded) (493 bytes, text/html)
2008-03-11 19:26 PDT, Jesse Ruderman
no flags Details
hack (1.26 KB, patch)
2008-05-03 01:40 PDT, Bernd
no flags Details | Diff | Splinter Review

Summon comment box

Description Jesse Ruderman 2008-03-11 19:26:06 PDT
Created attachment 308786 [details]
testcase (crashes Firefox when loaded)

Loading the testcase makes Firefox crash with nsOverflowContinuationTracker::Insert calling 0xdddddddd.
Comment 1 Bernd 2008-05-03 01:40:18 PDT
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.
Comment 2 fantasai 2008-05-03 08:02:02 PDT
I think the loop should be inside nsOverflowContinuationTracker::Finish.
Comment 3 fantasai 2008-05-04 12:18:25 PDT
Bernd asked me to take this.
Comment 4 Robert O'Callahan (:roc) (Mozilla Corporation) 2008-07-23 21:34:43 PDT
I'm rolling this patch into bug 422283.
Comment 5 Robert O'Callahan (:roc) (Mozilla Corporation) 2008-09-06 01:50:19 PDT
Fixed by checkin for 422283.
Comment 6 Daniel Veditz 2008-12-19 11:42:04 PST
"blocking" so we remember to verify when we land bug 422283 on the branch
Comment 7 Daniel Veditz 2009-01-08 00:12:37 PST
bug 422283 was checked into the 1.9.0 branch, we can verify this one now.
Comment 8 Alexander Sack 2009-01-08 06:15:11 PST
doesnt crash 1.8.1 here. and code from 422283 suggests that this is 1.9 and above only.
Comment 9 Al Billings [:abillings] 2009-01-13 18:25:17 PST
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.
Comment 10 Tony Chung [:tchung] 2009-01-30 17:37:14 PST
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

Note You need to log in before you can comment on or make changes to this bug.