292257 - [FIXr]Crash when visiting site [@ nsHTMLReflowState::ComputePadding]

Status: RESOLVED FIXED

(Core :: Layout, defect, P1)

Description

[Frank Wein [:mcsmurf]]

To reproduce:
1. Go to URL
2. See crash

This is a rather recent regression, so not the same as the other two crashers
with nsHTMLReflowState::ComputePadding in frame 0 of the stacktrace.
This regressed between 2005-02-18-06 and 2005-02-19-06.
Bonsai link:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&filetype=match&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-02-18+05%3A00%3A00&maxdate=2005-02-19+07%3A00%3A00&cvsroot=%2Fcvsroot

Stacktrace:
nsHTMLReflowState::ComputePadding(nsHTMLReflowState * const 0x02d28ea0, int
0x00000a8c, const nsHTMLReflowState * 0x0012e3ac) line 2435 + 2 bytes
nsHTMLReflowState::InitConstraints(nsHTMLReflowState * const 0x02d28ea0,
nsPresContext * 0x02c71d40, int 0x00000a8c, int 0x00000267, nsMargin *
0x00000000, nsMargin * 0x00000000) line 1718
nsHTMLReflowState::Init(nsHTMLReflowState * const 0x02d28ea0, nsPresContext *
0x02c71d40, int 0xffffffff, int 0xffffffff, nsMargin * 0x00000000, nsMargin *
0x00000000) line 337 + 22 bytes
nsHTMLReflowState::nsHTMLReflowState(nsHTMLReflowState * const 0x02d28ea0,
nsPresContext * 0x02c71d40, const nsHTMLReflowState & {...}, nsIFrame *
0x02d28ea0, const nsSize & {...}) line 261
nsObjectFrame::HandleChild(nsObjectFrame * const 0x02d28ea0, nsPresContext *
0x02c71d40, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...},
unsigned int & 0x00000000, nsIFrame * 0x02d28ea0) line 1446
nsObjectFrame::Reflow(nsObjectFrame * const 0x000000b4, nsPresContext *
0x02c71d40, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...},
unsigned int & 0x00000000) line 1041 + 20 bytes
nsLineLayout::ReflowFrame(nsLineLayout * const 0x02d28ea0, nsIFrame *
0x02ca819c, unsigned int & 0x00000000, nsHTMLReflowMetrics * 0x00000000, int &
0x00000000) line 999
nsInlineFrame::ReflowInlineFrame(nsInlineFrame * const 0x02d28ea0, nsPresContext
* 0x02c71d40, const nsHTMLReflowState & {...}, nsInlineFrame::InlineReflowState
& {...}, nsIFrame * 0x02ca819c, unsigned int & 0x00000000) line 712
nsInlineFrame::ReflowFrames(nsInlineFrame * const 0x02d28ea0, nsPresContext *
0x02c71d40, const nsHTMLReflowState & {...}, nsInlineFrame::InlineReflowState &
{...}, nsHTMLReflowMetrics & {...}, unsigned int & 0x00000000) line 530
nsInlineFrame::Reflow(nsInlineFrame * const 0x02ca80a4, nsPresContext *
0x02c71d40, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...},
unsigned int & 0x00000000) line 444
nsLineLayout::ReflowFrame(nsLineLayout * const 0x02d28ea0, nsIFrame *
0x02ca80a4, unsigned int & 0x00000000, nsHTMLReflowMetrics * 0x00000000, int &
0x00000000) line 999
nsBlockFrame::ReflowInlineFrame(nsBlockFrame * const 0x02d28ea0,
nsBlockReflowState & {...}, nsLineLayout & {...}, nsLineList_iterator {...},
nsIFrame * 0x00000000, unsigned char * 0x0012e763) line 4187 + 29 bytes
nsBlockFrame::DoReflowInlineFrames(nsBlockFrame * const 0x02d28ea0,
nsBlockReflowState & {...}, nsLineLayout & {...}, nsLineList_iterator {...}, int
* 0x0012e95c, unsigned char * 0x0012e82b, int 0x00000000, int 0x00000001) line 3840

Comment 1

[Frank Wein [:mcsmurf]]

-->invalid, i disabled the default plugin in Mozilla (via a pref) so i get the
plugin replacement FF uses. There a URL to a file is used which is only included
in FF. This invalid URL seems to cause the crash then. In a current FF trunk
build this works fine, so invalid.

Comment 2

[Frank Wein [:mcsmurf]]

Ok, real bug it seems.
Another (more useful) stacktrace with a debug build:
SizeAnchor(nsIContent * 0xdddddddd, int 0x000000b4, int 0x00000029) line 968
nsObjectFrame::Reflow(nsObjectFrame * const 0x055db690, nsPresContext *
0x049288e0, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...},
unsigned int & 0x00000000) line 1025 + 22 bytes
nsLineLayout::ReflowFrame(nsIFrame * 0x055db690, unsigned int & 0x00000000,
nsHTMLReflowMetrics * 0x00000000, int & 0x00000000) line 998 + 43 bytes
nsInlineFrame::ReflowInlineFrame(nsPresContext * 0x049288e0, const
nsHTMLReflowState & {...}, nsInlineFrame::InlineReflowState & {...}, nsIFrame *
0x055db690, unsigned int & 0x00000000) line 706 + 22 bytes
nsInlineFrame::ReflowFrames(nsPresContext * 0x049288e0, const nsHTMLReflowState
& {...}, nsInlineFrame::InlineReflowState & {...}, nsHTMLReflowMetrics & {...},
unsigned int & 0x00000000) line 529 + 28 bytes
nsInlineFrame::Reflow(nsInlineFrame * const 0x055db594, nsPresContext *
0x049288e0, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...},
unsigned int & 0x00000000) line 439 + 28 bytes
nsLineLayout::ReflowFrame(nsIFrame * 0x055db594, unsigned int & 0x00000000,
nsHTMLReflowMetrics * 0x00000000, int & 0x00000000) line 998 + 43 bytes
nsBlockFrame::ReflowInlineFrame(nsBlockReflowState & {...}, nsLineLayout &
{...}, nsLineList_iterator {...}, nsIFrame * 0x055db594, unsigned char *
0x0012d40f) line 4000 + 22 bytes
nsBlockFrame::DoReflowInlineFrames(nsBlockReflowState & {...}, nsLineLayout &
{...}, nsLineList_iterator {...}, int * 0x0012d7c4, unsigned char * 0x0012d51b,
int 0x00000000, int 0x00000001) line 3839 + 32 bytes
nsBlockFrame::ReflowInlineFrames(nsBlockReflowState & {...}, nsLineList_iterator
{...}, int * 0x0012d7c4, int 0x00000001, int 0x00000000) line 3722 + 46 bytes

Comment 3

[Frank Wein [:mcsmurf]]

Attachment: Testcase

Comment 4

[Boris Zbarsky [:bzbarsky]]

So what are the steps to reproduce staring from a vanilla profile?

Comment 5

[Frank Wein [:mcsmurf]]

Steps to reproduce:
1. Open about:config, create boolean pref plugin.default_plugin_disabled with
value true.
2. Restart Mozilla
3. Open testcase

Comment 6

[[e-mail]]

<rant> Why are we hardcoding skin image URLs in content anyway? If you want the
placeholder to be themable use an XBL binding with a scoped stylesheet. </rant>

BTW, what was chrome://mozapps/ created for and where is it documented?

Comment 7

[Boris Zbarsky [:bzbarsky]]

> <rant> Why are we hardcoding skin image URLs in content anyway?

Because "temporary" aviary branch stuff got landed on trunk and looks to become
permanent... :(

Might want to ask bsmedberg about mozapps.

In any case, I know what's going on here as far as the crash goes.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Attachment: Patch

In this case, Init() on the image frame returns failure (because it knows it
couldn't load the image, since the channel couldn't be opened, so it wants to
be replaced with its alt text).  In that case we call Destroy() on all the
frames we built, but we keep the pointer to the block in mFrames.  Then when we
go to reflow we crash (calling stuff on a destroyed frame, etc).

The patch just makes us not put anything in mFrames until we're sure that
everything has succeeded.

Comment 9

[[e-mail]]

(In reply to comment #7)
>Because "temporary" aviary branch stuff got landed on trunk and looks to become
>permanent... :(
That's bad news, considering the state it's in... just playing with the test
case throws up a number of other bugs:
* Placeholder not displayed if the image is removed from the test case.
* Placeholder not displayed after back/forward.
* Placeholder uses hardcoded style, then expects a PNG skin image.
* Final dimensions of embed object are 12px larger than width/height.
I notice that the string went in mozapps too, rather than like e.g. the html
form properties which live in chrome://global/locale/layout/.

Comment 10

[Johnny Stenback (:jst)]

And it'll remain that way until we get a generic mechanism for applying XBL
stylesheet to "broken" things, i.e. broken images, missing plugins, etc.

Comment 11

[Johnny Stenback (:jst)]

Comment on attachment 182374 [details] [diff] [review]
Patch

r=jst

Comment 12

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 182374 [details] [diff] [review]
Patch

Requesting approval for simple crash fix

Comment 13

[chris hofmann]

Comment on attachment 182374 [details] [diff] [review]
Patch

a=chofmann

Comment 14

[Boris Zbarsky [:bzbarsky]]

Fixed