Closed Bug 422301 Opened 16 years ago Closed 16 years ago

Crash [@ nsOverflowContinuationTracker::Insert] with -moz-column, padding, margin

Categories

(Core :: Layout, defect)

x86
macOS
defect
Not set
critical

Tracking

()

VERIFIED FIXED

People

(Reporter: jruderman, Assigned: fantasai.bugs)

References

Details

(4 keywords, Whiteboard: [sg:critical][fixed for 1.9.0 in bug 422283] post 1.8-branch)

Crash Data

Attachments

(2 files)

Loading the testcase makes Firefox crash with nsOverflowContinuationTracker::Insert calling 0xdddddddd.
Flags: blocking1.9?
Whiteboard: [sg:critical]
Flags: wanted1.9.0.x+
Flags: blocking1.9?
Flags: blocking1.9-
Attached patch hackSplinter Review
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.
Assignee: nobody → fantasai.bugs
I'm rolling this patch into bug 422283.
Depends on: 422283
Flags: blocking1.9.1?
Fixed by checkin for 422283.
Status: NEW → RESOLVED
Closed: 16 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Flags: blocking1.9.1? → blocking1.9.1+
Flags: blocking1.9.0.6?
"blocking" so we remember to verify when we land bug 422283 on the branch
Flags: blocking1.9.0.6? → blocking1.9.0.6+
Whiteboard: [sg:critical] → [sg:critical][fixed for 1.9.0 in bug 422283]
bug 422283 was checked into the 1.9.0 branch, we can verify this one now.
Keywords: fixed1.9.0.6
doesnt crash 1.8.1 here. and code from 422283 suggests that this is 1.9 and above only.
Flags: wanted1.8.1.x-
Flags: wanted1.8.0.x-
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
Status: RESOLVED → VERIFIED
Group: core-security
Whiteboard: [sg:critical][fixed for 1.9.0 in bug 422283] → [sg:critical][fixed for 1.9.0 in bug 422283] post 1.8-branch
Crash Signature: [@ nsOverflowContinuationTracker::Insert]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: