325047 - Crash on reload with evil testcase, using legends, position:absolute and display:table-row [@ nsFrameList::DestroyFrames]

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[Martijn Wargers (dead)]

See upcoming testcase, which crashes when I reload it.
This regressed between 2005-01-03 and 2005-06-01 (Ria, could you narrow it down further?).

Comment 1

[Martijn Wargers (dead)]

Attachment: testcase (crashes on reload)

Comment 2

[Martijn Wargers (dead)]

Attachment: backtrace from assertion, and crash

I get some assertions during the first load:
###!!! ASSERTION: prev sibling not in line list: 'Not Reached', file c:/mozilla/
mozilla/layout/generic/nsBlockFrame.cpp, line 5316
Break: at file c:/mozilla/mozilla/layout/generic/nsBlockFrame.cpp, line 5316
(I've attached the backtrace of that one)

###!!! ASSERTION: Float frame has wrong parent: 'floatFrame->GetParent() == mBlo
ck', file c:/mozilla/mozilla/layout/generic/nsBlockReflowState.cpp, line 838
Break: at file c:/mozilla/mozilla/layout/generic/nsBlockReflowState.cpp, line 83


###!!! ASSERTION: Expected to solve for left: 'NS_AUTOOFFSET == kidReflowState.m
ComputedOffsets.left', file c:/mozilla/mozilla/layout/generic/nsAbsoluteContaini
ngBlock.cpp, line 563
Break: at file c:/mozilla/mozilla/layout/generic/nsAbsoluteContainingBlock.cpp,
line 563

And the crash itself:
rogram received signal SIGSEGV, Segmentation fault.
0x04f9ec99 in nsFrameList::DestroyFrames(nsPresContext*) (this=0x102e8304,
    aPresContext=0x10037830)
    at c:/mozilla/mozilla/layout/generic/nsFrameList.cpp:138
138         frame->Destroy(aPresContext);
Current language:  auto; currently c++
(gdb) bt
#0  0x04f9ec99 in nsFrameList::DestroyFrames(nsPresContext*) (
    this=0x102e8304, aPresContext=0x10037830)
    at c:/mozilla/mozilla/layout/generic/nsFrameList.cpp:138
#1  0x04f6798f in nsBlockFrame::Destroy(nsPresContext*) (this=0x102e82c0,
    aPresContext=0x10037830)
    at c:/mozilla/mozilla/layout/generic/nsBlockFrame.cpp:296
#2  0x04f65eba in nsAreaFrame::Destroy(nsPresContext*) (this=0x102e82c0,
    aPresContext=0x10037830)
    at c:/mozilla/mozilla/layout/generic/nsAreaFrame.cpp:147
#3  0x04f9ec9d in nsFrameList::DestroyFrames(nsPresContext*) (
    this=0x102e8148, aPresContext=0x10037830)
    at c:/mozilla/mozilla/layout/generic/nsFrameList.cpp:138
#4  0x04f6798f in nsBlockFrame::Destroy(nsPresContext*) (this=0x102e8104,
    aPresContext=0x10037830)
    at c:/mozilla/mozilla/layout/generic/nsBlockFrame.cpp:296
#5  0x04f65eba in nsAreaFrame::Destroy(nsPresContext*) (this=0x102e8104,
    aPresContext=0x10037830)
    at c:/mozilla/mozilla/layout/generic/nsAreaFrame.cpp:147
#6  0x0502dcfa in nsLegendFrame::Destroy(nsPresContext*) (this=0x102e8104,
    aPresContext=0x10037830)
etc

Comment 3

[Ria Klaassen (not reading all bugmail)]

1.8b_2005012507 fails
1.8b_2005012407 works

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-01-24+06%3A00%3A00&maxdate=2005-01-25+07%3A00%3A00&cvsroot=%2Fcvsroot

Comment 4

[Bernd]

sounds like bug 276104?

Comment 5

[Boris Zbarsky [:bzbarsky]]

Does this also crash with builds after 2006-01-18?  I see an assert, but no crash...  Also, could this have gotten better with bug 310638?

Comment 6

[Martijn Wargers (dead)]

> Does this also crash with builds after 2006-01-18? 
Yes, I just crashed with a 2006-01-29 build, Talkback ID: TB14534462Y

Comment 7

[Boris Zbarsky [:bzbarsky]]

Hmm.  So I do see this in an optimized build with symbols.  Debug builds do NOT crash.  Something weird is up with floats in debug builds; this is the second such case recently where opt builds crash on float stuff and debug builds do not.

Aside from that, it seems to me that something _really_ wacky is happening.  The frame tree looks ok when I just load the page (in a debug build), but in the opt build we're dying because the floating span has a dead frame in its float list (!).  I have no idea how that got there, but I bet BuildFloatList is to blame -- if I make that function a no-op, this crash goes away.

Comment 8

[Jesse Ruderman]

WFM on Mac and Windows, using builds from before BuildFloatList removal but not more than two weeks old.

Martijn, do you still see this crash?

Comment 9

[Martijn Wargers (dead)]

(In reply to comment #8)
> Martijn, do you still see this crash?

No, tested with 2006-04-10 build, so marking wfm.

Comment 10

[Boris Zbarsky [:bzbarsky]]

This got fixed somewhere in the range:

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaTinderboxAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-03-15+03&maxdate=2006-03-17+02&cvsroot=%2Fcvsroot

no idea why.