Crash [@ CalcQuirkContainingBlockHeight]

RESOLVED FIXED in mozilla11



8 years ago
7 years ago


(Reporter: martijn.martijn, Assigned: bzbarsky)


(Blocks: 1 bug, {crash})

Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox8 affected, firefox9 affected, firefox10 affected)


(crash signature, URL)


(1 attachment)



8 years ago
I have an unminimized testcase with this crash stack:
0 	xul.dll 	CalcQuirkContainingBlockHeight 	layout/generic/nsHTMLReflowState.cpp:1548
1 	xul.dll 	nsHTMLReflowState::InitConstraints 	
2 	xul.dll 	nsTArray<nsIFrame*,nsTArrayDefaultAllocator>::Clear 	obj-firefox/dist/include/nsTArray.h:886
3 	xul.dll 	nsStyleContext::DoGetStylePadding 	obj-firefox/dist/include/nsStyleStructList.h:139
4 	xul.dll 	nsHTMLReflowState::Init 	layout/generic/nsHTMLReflowState.cpp:282

Dumping it here, maybe someone can fix it by looking at the stack.
Is it a regression?

Comment 2

8 years ago
It's also happening in a 2011-08-24 build, so it's not a regression from bug 679933.
I'll try to get a testcase next week or so.
It's a null deref crash on this code:


rs is known-null here, so I would guess rs->parentReflowState is null.

Martijn, can you attach the unminimized testcase?  Might well be fixable from that.

Comment 4

7 years ago

Nightly, Aurora, Beta - Linux, Mac, Windows.
Blocks: 532972
status-firefox10: --- → affected
status-firefox8: --- → affected
status-firefox9: --- → affected
Bob, thanks!

As expected, rs->parentReflowState is null.

rs->frame->mContent is a nsSVGForeignObjectElement, and rs->frame is correctly an nsBlockFrame.

Sounds like our basic assumption here is that an nsBlockFrame can't be a reflow root, and that's just not true.

We probably just need to add a null-check for rs->parentReflowState.
Created attachment 572392 [details] [diff] [review]
Add a null-check to avoid bogus assumptions about blocks not being reflow roots.
Attachment #572392 - Flags: review?(matspal)
Assignee: nobody → bzbarsky
Priority: -- → P2
Whiteboard: [need review]
Shouldn't the fixed height of a foreignObject be relevant when computing percentage heights on its kids?  (If it is, why are we in this code?)
> Shouldn't the fixed height of a foreignObject be relevant when computing percentage
> heights on its kids? 

It is, but in this case we have a percent-height kid of an auto height kid of the <foreignObject>.  And the page is in quirks mode, so the innermost block ends up in CalcQuirkContainingBlockHeight.

Or did I misunderstand your question?
Attachment #572392 - Flags: review?(matspal) → review+
OS: Windows 7 → All
Hardware: x86 → All
Whiteboard: [need review]
Flags: in-testsuite+
Target Milestone: --- → mozilla11
Last Resolved: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.