Last Comment Bug 683712 - Crash [@ CalcQuirkContainingBlockHeight]
: Crash [@ CalcQuirkContainingBlockHeight]
Status: RESOLVED FIXED
: crash
Product: Core
Classification: Components
Component: Layout (show other bugs)
: Trunk
: All All
: P2 critical (vote)
: mozilla11
Assigned To: Boris Zbarsky [:bz] (Out June 25-July 6)
:
Mentors:
http://www.mxgraph.com/demo/markup/we...
Depends on:
Blocks: 532972
  Show dependency treegraph
 
Reported: 2011-08-31 13:55 PDT by Martijn Wargers [:mwargers] (not working for Mozilla)
Modified: 2011-11-09 05:33 PST (History)
5 users (show)
bzbarsky: in‑testsuite+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
affected
affected
affected


Attachments
Add a null-check to avoid bogus assumptions about blocks not being reflow roots. (1.89 KB, patch)
2011-11-06 21:46 PST, Boris Zbarsky [:bz] (Out June 25-July 6)
mats: review+
Details | Diff | Review

Description Martijn Wargers [:mwargers] (not working for Mozilla) 2011-08-31 13:55:23 PDT
I have an unminimized testcase with this crash stack:

https://crash-stats.mozilla.com/report/index/bp-184613e9-30b4-4e36-a653-a75352110831
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.
Comment 1 Mats Palmgren (:mats) 2011-08-31 14:35:57 PDT
Is it a regression?
Comment 2 Martijn Wargers [:mwargers] (not working for Mozilla) 2011-08-31 14:47:35 PDT
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.
Comment 3 Boris Zbarsky [:bz] (Out June 25-July 6) 2011-08-31 21:11:30 PDT
It's a null deref crash on this code:

  rs->parentReflowState->frame->GetType()

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 Bob Clary [:bc:] 2011-11-06 05:18:44 PST
http://www.mxgraph.com/demo/markup/webkitbg.html

Nightly, Aurora, Beta - Linux, Mac, Windows.
Comment 5 Boris Zbarsky [:bz] (Out June 25-July 6) 2011-11-06 21:35:11 PST
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.
Comment 6 Boris Zbarsky [:bz] (Out June 25-July 6) 2011-11-06 21:46:28 PST
Created attachment 572392 [details] [diff] [review]
Add a null-check to avoid bogus assumptions about blocks not being reflow roots.
Comment 7 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2011-11-06 22:24:46 PST
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?)
Comment 8 Boris Zbarsky [:bz] (Out June 25-July 6) 2011-11-07 21:11:47 PST
> 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?
Comment 9 Boris Zbarsky [:bz] (Out June 25-July 6) 2011-11-08 20:23:13 PST
http://hg.mozilla.org/integration/mozilla-inbound/rev/898f04b9db6b
Comment 10 Marco Bonardo [::mak] 2011-11-09 05:33:59 PST
https://hg.mozilla.org/mozilla-central/rev/898f04b9db6b

Note You need to log in before you can comment on or make changes to this bug.