[FIX]Crash [@ nsSubDocumentFrame::Reflow] with evil testcase, using ::before, ::after and display: table-row a lot

VERIFIED FIXED in mozilla1.9alpha1

Status

()

P2
critical
VERIFIED FIXED
13 years ago
8 years ago

People

(Reporter: martijn.martijn, Assigned: bzbarsky)

Tracking

({crash, regression, testcase})

Trunk
mozilla1.9alpha1
crash, regression, testcase
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9 +
blocking1.9a1 +

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(3 attachments)

(Reporter)

Description

13 years ago
See upcoming testcase, which crashes current trunk Mozilla builds. (unfortunately, not too minimised)
Doesn't crash in 2006-04-10 build, crashes in 2006-04-11 build:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-04-10+11&maxdate=2006-04-11+07&cvsroot=%2Fcvsroot

The only thing that could have caused this, seems to me bug 332927.

Talkback ID: TB18324960W
nsSubDocumentFrame::Reflow   nsLineLayout::ReflowFrame  

Maybe this gets 'automatically' fixed by the reflow branch?
(Reporter)

Comment 1

13 years ago
Created attachment 220905 [details]
testcase, crashes on load
(Reporter)

Comment 2

13 years ago
Created attachment 220906 [details]
Backtrace from debug build

Prior to the crash, I get this assertion (stack included):
###!!! ASSERTION: DeletingFrameSubtree on a special frame.  Prepare to crash.: '
!IsFrameSpecial(aFrame)', file c:/mozilla/mozilla/layout/base/nsCSSFrameConstruc
tor.cpp, line 9845

And then the crash:
#0  0x059f0c6e in nsIView::GetViewManager() const (this=0x0)
    at ../../../../dist/include/view/nsIView.h:144
#1  0x0536331f in nsSubDocumentFrame::Reflow(nsPresContext*, nsHTMLReflowMetrics
&, nsHTMLReflowState const&, unsigned&) (this=0x101aceb0,
    aPresContext=0x1013b308, aDesiredSize=@0x22c1f8, aReflowState=@0x22c248,
    aStatus=@0x22c3c0)
    at c:/mozilla/mozilla/layout/generic/nsFrameFrame.cpp:392
#2  0x05395653 in nsLineLayout::ReflowFrame(nsIFrame*, unsigned&, nsHTMLReflowMe
trics*, int&) (this=0x22c4a8, aFrame=0x101aceb0, aReflowStatus=@0x22c3c0,
    aMetrics=0x0, aPushedFrame=@0x22c3bc)
    at c:/mozilla/mozilla/layout/generic/nsLineLayout.cpp:996
(Assignee)

Comment 3

13 years ago
So the problem is that in nsCSSFrameConstructor::WipeContainingBlock we end up finding the block inside the pseudo table-cell.  We want to keep going up through the table pseudos until we find an honest block.  Possibly just fixing this loop condition:

  while (IsFrameSpecial(aContainingBlock))
    aContainingBlock = aContainingBlock->GetParent();

would work.  Bernd, do we have a way to detect table pseudo-frames?
Flags: blocking1.9a1?

Comment 4

13 years ago
sure we have, see the patch in bug 162063
(Assignee)

Comment 5

13 years ago
Created attachment 220946 [details] [diff] [review]
Proposed patch

OK, I think the right thing to do here is to walk out of all pseudos, not just table pseudos.  Safer that way, esp. if we ever start supporting things like positioned anonymous content (which could then be block-level even if the parent is inline).
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Attachment #220946 - Flags: superreview?(dbaron)
Attachment #220946 - Flags: review?(dbaron)
(Assignee)

Updated

13 years ago
OS: Windows XP → All
Priority: -- → P2
Hardware: PC → All
Summary: Crash with evil testcase, using ::before, ::after and display: table-row a lot → [FIX]Crash with evil testcase, using ::before, ::after and display: table-row a lot
Target Milestone: --- → mozilla1.9alpha
(Reporter)

Updated

13 years ago
Summary: [FIX]Crash with evil testcase, using ::before, ::after and display: table-row a lot → [FIX]Crash [@ nsSubDocumentFrame::Reflow] with evil testcase, using ::before, ::after and display: table-row a lot
(Reporter)

Updated

13 years ago
Blocks: 339249

Updated

13 years ago
Flags: blocking1.9a1? → blocking1.9a1+

Updated

12 years ago
Blocks: 345857

Comment 6

12 years ago
@ nsSubDocumentFrame::Reflow is nowadays a trunk topcrasher.
(Assignee)

Updated

12 years ago
Attachment #220946 - Flags: superreview?(roc)
Attachment #220946 - Flags: superreview?(dbaron)
Attachment #220946 - Flags: review?(roc)
Attachment #220946 - Flags: review?(dbaron)
Attachment #220946 - Flags: superreview?(roc)
Attachment #220946 - Flags: superreview+
Attachment #220946 - Flags: review?(roc)
Attachment #220946 - Flags: review+
You may want to add a comment for posterity, noting that "overshooting" and reframing more than we need to is safe.
(Assignee)

Comment 8

12 years ago
Checked in, with a comment to that effect.
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Verified FIXED using 2006-11-13-09 of SeaMonkey trunk under Windows XP on the testcase: https://bugzilla.mozilla.org/attachment.cgi?id=220905.  No crash.
Status: RESOLVED → VERIFIED
Crash Signature: [@ nsSubDocumentFrame::Reflow]
You need to log in before you can comment on or make changes to this bug.