Crash [@ nsLineBox::CachedIsEmpty] with -moz-column, huge padding

RESOLVED WORKSFORME

Status

()

defect
--
critical
RESOLVED WORKSFORME
11 years ago
8 years ago

People

(Reporter: jruderman, Assigned: mats)

Tracking

(Blocks 2 bugs, {crash, testcase})

Trunk
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(2 attachments)

Reporter

Description

11 years ago
###!!! ASSERTION: Computed overflow area must contain frame bounds: 'aNewSize.width == 0 || aNewSize.height == 0 || aOverflowArea->Contains(nsRect(nsPoint(0, 0), aNewSize))', file /Users/jruderman/central/layout/generic/nsFrame.cpp, line 5618

###!!! ASSERTION: illegal height for combined area: 'aCombinedArea.height >= 0', file /Users/jruderman/central/layout/generic/nsLineBox.cpp, line 499

###!!! ASSERTION: illegal width for combined area: 'aCombinedArea.width >= 0', file /Users/jruderman/central/layout/generic/nsLineBox.cpp, line 498

Null-dereference crash [@ nsLineBox::CachedIsEmpty]
Assignee

Comment 1

11 years ago
It's a bug in nsBlockFrame::DoRemoveFrame....
Assignee: nobody → mats.palmgren
Component: Layout → Layout: Block and Inline
OS: Mac OS X → All
QA Contact: layout → layout.block-and-inline
Hardware: x86 → All
Assignee

Comment 2

11 years ago
Posted file Frame dumps
DoRemoveFrame removes the frame (green) and finds that the line is now
empty so it removes that too, then tries to find the continuation, but
since it's not on the next line we try to advance to the overflow-lines
instead, on line 5526:
http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsBlockFrame.cpp#5502
this triggers the code block 5533 - 5537 which sets the next-sibling
of (red) to null. There are no overflow-lines so we fall into the
RemoveBlockChild call at the end, which recursively calls DoRemoveFrame,
(the next frame dump is for this call).  Note the error that frames
on the two lines are not connected with a next-sibling pointer.
The (blue) frame is removed ok and we return (with the last frame
dump as the final resulting frame tree).

The disconnected frames cause problems later in PullFrameFrom:
http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsBlockFrame.cpp#2410
which depends on the invariant "when aFromContainer is 'this', then
aLine->LastChild()'s next sibling is already set correctly.", when the
line's child count is incremented on line 2445 the count exceeds
the number of siblings and mayhem ensues...

Comment 3

10 years ago
wfm 1.9.2
Reporter

Comment 4

10 years ago
Still crashes for me on mozilla-central.
Reporter

Comment 5

10 years ago
WFM on mozilla-central now.

Mats, does the issue described in comment 2 still exist?
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
Reporter

Comment 6

10 years ago
Added crashtest:

http://hg.mozilla.org/mozilla-central/rev/543def0d7efb
Flags: in-testsuite+
Crash Signature: [@ nsLineBox::CachedIsEmpty]
You need to log in before you can comment on or make changes to this bug.