Closed Bug 495892 Opened 15 years ago Closed 15 years ago

Crash [@ nsStyleContext::FindChildWithRules] with -moz-column, {ib}, caption, colgroup

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: jruderman, Unassigned)

References

Details

(Keywords: crash, testcase, Whiteboard: [sg:critical?])

Crash Data

Attachments

(1 file)

testcase (crashes Firefox when loaded)
439 bytes, application/xhtml+xml
Details 
Crash [@ nsStyleContext::FindChildWithRules] touching 0xdddddde1.
Whiteboard: [sg:critical?]
Still crashes on mozilla-central.
Hrm.  The aParentContext here is a dead object (as expected from comment 0):

(gdb) p parentContext
$5 = (nsStyleContext *) 0xf0dea7ff

Zack, that looks like poison, right?

More debugging tomorrow.
(In reply to comment #2)
> (gdb) p parentContext
> $5 = (nsStyleContext *) 0xf0dea7ff
> 
> Zack, that looks like poison, right?

Yup, that's poison.
Out of curiosity, Jesse, does this crash if you don't use the "q.parentNode.removeChild" construct, but get the <head> node some other way?
OK, two additional pieces of data:

1)  Something in one of my trees fixes this bug; my money is on bug 501847.
2)  In a tree that does show the problem, the {ib} linkage is clearly busted; in
    particular a frametree dump shows the block part of such a split without an
    inline part preceding it.  Something went seriously wrong there.
OK.  So we have a frametree that contains this bit:

                      Inline(span)(0)@0x20224968 next=0x202249d0 prev-continuation=0x202230e8 next-continuation=0x202249d0 {0,1248,0,960} [state=00008004] [content=0x1ffa3b80] [sc=0x20221fb8]Overflow-list<
                        Inline(span)(2)@0x20223b68 {0,0,480,960} [state=00008000] [content=0x1ff9ca20] [sc=0x20222660]<
                          Inline(span)(0)@0x20223ba8 {480,0,0,960} [content=0x1ffa4230] [sc=0x20223038]<>
                        >
                      >

where the span that's on the overflow list (0x20223b68) is the first part of an ib split.  Then we call nsBlockFrame::DeleteNextInFlowChild on the span that has the overflow list (0x20224968), which kills it and all its descendants, including 0x20223b68.  After this the blockframe from that {ib} split has a dangling IBSplitSpecialPrevSibling property, and we lose.
So any bright ideas for why we'd be returning complete when we have a next-in-flow with frames on its overflow list?
Note that I doubt bug 501847 fixes the underlying issue here; it probably just changes the frame tree enough that the bug doesn't show up with this particular testcase...
The patch for bug 523468 does NOT fix this bug.

That said, with poisoning this looks like sg:dos, not sg:critical.
> Out of curiosity, Jesse, does this crash if you don't use the
> "q.parentNode.removeChild" construct, but get the <head> node some other way?

Yes, still crashes if I use getElementById("head").
WFM on trunk.  fantasai's frame destruction patches in bug 508473 fixed several -moz-column bugs, so they might have fixed this as well.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
Crash Signature: [@ nsStyleContext::FindChildWithRules]
Group: core-security → core-security-release
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: