Closed Bug 537645 Opened 15 years ago Closed 15 years ago

Crash [@ nsStyleContext::FindChildWithRules] with -moz-column, spacer, caption

Categories

(Core :: Layout, defect)

x86
macOS
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla1.9.3a1

People

(Reporter: jruderman, Assigned: tnikkel)

References

Details

(Keywords: crash, testcase, Whiteboard: [sg:critical?] mitigated by frame poisoning)

Crash Data

Attachments

(3 files)

Attached file testcase (crashes when loaded) (deleted) —
No description provided.
Attached file stack trace (deleted) —
When we crash, the aParentContext pointer passed to nsStyleSet::ResolveAnonymousBoxStyle is 0xf0dea7ff (so frame poison).
And that happens because providerFrame is poisoned. aFrame as passed to ReResolveStyleContext is a -moz-anonymous-block pseudo-frame. Its IBPreviousSibling pointer is pointing to providerFrame (as expected), and that frame is NOT in the frametree.
If don't run the onload handler, then the ib inlines are also missing from the frame tree. If I don't put a margin on "span", then they're present in the frametree, as expected. Breaking on nsFrame::DestroyFrom methods, it looks like the ib prevsibling is destroyed from nsContainerFrame::DestroyOverflowList called from nsContainerFrame::Destroy called from nsBlockFrame::DeleteNextInFlowChild. And in particular, we're destroying the next-in-flow of the frame which parents the <spacer> and the inline-table which wraps the <caption>. This is the ib first sibling for the outer span; the ib first siblings for the inner two nested spans seem to be on the overflow list of this continuation we're deleting, with the result that we kill them off. roc, mats, tn, any idea what's going on here?
Attached patch patch (deleted) — Splinter Review
In nsInlineFrame::ReflowFrames for the first continuation of the most outer span, after reflowing all of our frames we try to pull frames from next in flows with PullOneFrame. As in comment 4, the next in flow has the first (inline) part of the ib-split on its overflow list and no frames on its principle childlist. So we skip over it and look in the next continuation. Bug 533379 fixed a similar problem if PullOneFrame removed the last frame from the principle childlist. But in this case the principle childlist starts out empty.
Assignee: nobody → tnikkel
Attachment #422482 - Flags: review?(bzbarsky)
Comment on attachment 422482 [details] [diff] [review] patch s/principle/principal/ and looks good.
Attachment #422482 - Flags: review?(bzbarsky) → review+
Status: NEW → RESOLVED
Closed: 15 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a1
This does something very similar to (one half of) bug 533379, so if we take this on branch we would want that too.
Crash Signature: [@ nsStyleContext::FindChildWithRules]
Group: core-security
Flags: in-testsuite? → in-testsuite+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: