[FIX]Crash [@ nsCellMapColumnIterator::GetNextFrame] with floated table cell and xul:box

RESOLVED FIXED in mozilla1.9alpha3

Status

()

Core
Layout: Tables
--
critical
RESOLVED FIXED
11 years ago
7 years ago

People

(Reporter: Jesse Ruderman, Assigned: bz)

Tracking

(Blocks: 1 bug, {crash, testcase})

Trunk
mozilla1.9alpha3
x86
Mac OS X
crash, testcase
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(2 attachments)

(Reporter)

Description

11 years ago
Created attachment 256145 [details]
testcase

Loading this testcase makes Firefox crash [@ nsCellMapColumnIterator::GetNextFrame], even with the patch for bug 371290.  In a debug build, I see two assertions before the crash:

###!!! ASSERTION: GetMapFor called with continuation: '!aRowGroup->GetPrevInFlow()', file /Users/jruderman/trunk/mozilla/layout/tables/nsCellMap.cpp, line 282

###!!! ASSERTION: Bogus mOrigCells?: 'mCurMapRow < mCurMapRelevantRowCount', file /Users/jruderman/trunk/mozilla/layout/tables/nsCellMap.cpp, line 2798
Hey, it _is_ a bogus mOrigCells!  There's a single nsCellMap involved, and it has a single content row (and only one entry in mRows).  But mOrigCells is 2.
Oh, and the table is somehow ending up having a next in flow?
And this next-in-flow seems to have a single row in it, which explains the discrepancy.

Sounds like figuring out why we have a next-in-flow is the way to go. 
Looks like we get a NS_FRAME_IS_NOT_COMPLETE when nsTableFrame calls ReflowChild on the rowgroup.  _That_'s probably the fault of the XUL.

Gotta sleep now; will look more tomorrow.

Comment 5

11 years ago
hmm, GetNextFrame a living demonstration for the meaning of the german word
Sollbruchstelle (http://de.wiktionary.org/wiki/Sollbruchstelle)
If we're still hitting these issues as we get closer to 1.9 final there are ways to make GetNextFrame a little safer (at some sacrifice in speed).  But while it's letting us find bugs, I say we let it do so.  ;)
When the block reflows we're coming out with an aMetrics.height that's bigger than NS_UNCONSTRAINEDSIZE.  This causes NS_FRAME_SET_TRUNCATION to claim the block is truncated, etc.
When reflowing the checkbox (which is a child of a box), we init a root reflow state (no parent) with an unconstrained available height.  Then we do arithmetic on said height in nsHTMLReflowState::InitConstraints.  Which gives us a constrained very very large height, which is bad.
Created attachment 256252 [details] [diff] [review]
This fixes the crash...
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Attachment #256252 - Flags: superreview?(dbaron)
Attachment #256252 - Flags: review?(dbaron)

Updated

11 years ago
Flags: in-testsuite?
Summary: Crash [@ nsCellMapColumnIterator::GetNextFrame] with floated table cell and xul:box → [FIX]Crash [@ nsCellMapColumnIterator::GetNextFrame] with floated table cell and xul:box
Target Milestone: --- → mozilla1.9alpha3
Comment on attachment 256252 [details] [diff] [review]
This fixes the crash...

r+sr=dbaron
Attachment #256252 - Flags: superreview?(dbaron)
Attachment #256252 - Flags: superreview+
Attachment #256252 - Flags: review?(dbaron)
Attachment #256252 - Flags: review+
Checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED

Updated

11 years ago
Blocks: 371681
(Reporter)

Comment 12

11 years ago
Crashtest checked in.
Flags: in-testsuite? → in-testsuite+
Crash Signature: [@ nsCellMapColumnIterator::GetNextFrame]
You need to log in before you can comment on or make changes to this bug.