Closed
Bug 537645
Opened 15 years ago
Closed 15 years ago
Crash [@ nsStyleContext::FindChildWithRules] with -moz-column, spacer, caption
Categories
(Core :: Layout, defect)
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)
No description provided.
Reporter | ||
Comment 1•15 years ago
|
||
Comment 2•15 years ago
|
||
When we crash, the aParentContext pointer passed to nsStyleSet::ResolveAnonymousBoxStyle is 0xf0dea7ff (so frame poison).
Comment 3•15 years ago
|
||
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.
Comment 4•15 years ago
|
||
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?
Assignee | ||
Comment 5•15 years ago
|
||
Assignee | ||
Comment 6•15 years ago
|
||
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 7•15 years ago
|
||
Comment on attachment 422482 [details] [diff] [review]
patch
s/principle/principal/ and looks good.
Attachment #422482 -
Flags: review?(bzbarsky) → review+
Assignee | ||
Comment 8•15 years ago
|
||
Status: NEW → RESOLVED
Closed: 15 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a1
Assignee | ||
Comment 9•15 years ago
|
||
This does something very similar to (one half of) bug 533379, so if we take this on branch we would want that too.
Updated•13 years ago
|
Crash Signature: [@ nsStyleContext::FindChildWithRules]
Comment 10•11 years ago
|
||
Landed the crash test:
https://hg.mozilla.org/integration/mozilla-inbound/rev/56e9f8640762
Group: core-security
Flags: in-testsuite? → in-testsuite+
Comment 11•11 years ago
|
||
You need to log in
before you can comment on or make changes to this bug.
Description
•