228557 - M17x FF104 Crash on provided URL [@ nsHTMLReflowState::Init]

Status: RESOLVED WORKSFORME

Description

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031015
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031015

I will attach a call stack.

Reproducible: Always

Steps to Reproduce:
1. Visit the provided URL, observe crash.

Actual Results:  
Crash

Expected Results:  
Show me the page

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031015
I recompiled it a couple days ago from CVS, so it's newer than 10/15

Comment 1

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Created attachment 137456 [details]
Call stack

Comment 2

[José Jeria]

WFM, 20031211, Windows XP

Comment 3

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Commenting out this:
DisplayAds
("entertainment.howstuffworks.com/camera.htm","Top,Bottom,Right,Right1,Right2,Right3,x01,x02,Middle,Middle1!Right","120","600")

in the javascript made it work.  It was the ad in the left navbar, between
"Sponsored By:" and "Categories".

Comment 4

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Using Ethereal, the last ad request that Moz made was for
http://ad.howstuffworks.com/RealMedia/ads/adstream_jx.ads/entertainment.howstuffworks.com/camera.htm/1641560842@Top,Bottom,Right,Right1,Right2,Right3,x01,x02,Middle,Middle1!Right

which returns the following:

document.write ('<!-- begin ZEDO -->\n');
document.write ('<script language="JavaScript">\n');
document.write ('var zflag_nid="162"; var zflag_cid="9/1"; var zflag_sid="8";
var zflag_width="120"; var zflag_height="600"; var zflag_sz="8"; \n');
document.write ('</script>\n');
document.write ('<iframe
src="http://c1.zedo.com/jsc/c1/ff2.html?n=162;c=9/1;s=8;d=8;w=120;h=600" 
frameborder=0 marginheight=0 marginwidth=0 scrolling="no"
allowTransparency="true" width=120 height=600>\n');
document.write ('<script language="JavaScript"
src="http://c1.zedo.com/jsc/c1/ff2.js"></script>\n');
document.write ('<noscript>\n');
document.write ('<a
href="http://xads.zedo.com/ads2/r?n=162;c=9/1;s=8;x=2048;u=j;z=2003.12.15.16.43.37"
target="_blank"><img border="0" width="120" height="600"
src="http://xads.zedo.com/ads2/x?n=162;c=9/1;s=8;x=2048;u=j;z=2003.12.15.16.43.37"
alt="Click here"></a>\n');
document.write ('</noscript>\n');
document.write ('</iframe>\n');
document.write ('<!-- end ZEDO -->');

Comment 5

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Hmm, that URL is returning something different now :(

Comment 6

[Malcolm Rowe]

The line numbers are all out with reference to the current trunk, even though 
the files haven't changed recently. Do you have anything odd in your tree?

The call stack is interesting (by which I mean, 'weird'). Start here:

nsContainerFrame::ReflowChild(nsContainerFrame * const 0x0012a2b4, nsIFrame * 
0x01dbbdc8, nsIPresContext * 0x01dc03c0, nsHTMLReflowMetrics & {...}, const 
nsHTMLReflowState & {...}, int 0, int 0, unsigned int 0, unsigned int & 0) line 
966

nsIFrame * aKidFrame is 0x01dbbdc8, which looks ok.

We then do:
939   aKidFrame->WillReflow(aPresContext);
940 
941   if (0 == (aFlags & NS_FRAME_NO_MOVE_FRAME)) {
942     aKidFrame->SetPosition(nsPoint(aX, aY));
943   }
944 
945   if (0 == (aFlags & NS_FRAME_NO_MOVE_VIEW)) {
946     PositionFrameView(aPresContext, aKidFrame);
947   }
948 
949   // Reflow the child frame
950   result = aKidFrame->Reflow(aPresContext, aDesiredSize, aReflowState,
951                              aStatus);

Which gets to:

nsTableCellFrame::Reflow(nsTableCellFrame * const 0x00000000, nsIPresContext * 
0x01dc03c0, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, 
unsigned int & 0) line 892

Where 'this' (aKidFrame from ReflowChild, as a nsTableCellFrame *) is null, 
eventually causing the crash. Presumably, aKidFrame->WillReflow succeeds 
because the implementation is on nsFrame.

Comment 7

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

> Do you have anything odd in your tree?

A while back I tested roc's w3c opacity patch, but since then I thought I
cleaned my tree up.  CVS checkout showed no M or C, so that leads me to believe
my tree is OK.  Should I delete it and start clean anyway?

Comment 8

[Malcolm Rowe]

> Should I delete it and start clean anyway?

If you have a testcase (and the time), sure.

Can you still reproduce this? If so, could you attach a reduced testcase before 
you clean your tree? (maybe not a *minimal* testcase, but certainly not 
something that depends upon external ad servers).

That way, we can at least confirm that the problem is resolved (or not).

Comment 9

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Created attachment 137465 [details]
Reduced testcase

This is about as small as I can make it.  Remove the google search, it works. 
Remove the flash object, and it works.	Remove the <map>, and it works.  Remove
some of the stuff in the <head>, and it works.

I don't know how many ads they have in the rotation, but it crashes pretty
reliabily.

I'm in the process of checking out the tree from scratch & rebuilding, but that
probably won't finish until tomorrow.

Comment 10

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Created attachment 137504 [details]
New call stack

I built from a tree in a different location, using a different objdir, and I'm
still crashing.  I have autoscroll and flash click to view installed.

My .mozconfig follows:
export MOZ_PROFILE=1
ac_add_options --enable-crypto
ac_add_options --disable-tests
ac_add_options --disable-debug
ac_add_options --enable-optimize
#ac_add_options --disable-ldap
ac_add_options
--enable-extensions=cookie,xml-rpc,xmlextras,p3p,pref,transformiix,universalchardet,typeaheadfind,webservices

ac add_options --enable-mathml
#ac_add_options --enable-static
#ac_add_options --disable-shared
ac_add_options --disable-accessibility
mk_add_options MOZ_OBJDIR=../mozbuild

Comment 11

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

My tree is available <a href="http://ctho9305.ath.cx:8080/moztree/">here</a> (it
probably won't be available from Tuesday evening until late Wednesday as I'm
moving) if you want to look at my versions of the various files.

The new user-agent is Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b)
Gecko/20031215

I did a "cvs checkout", created my mozconfig, did a "make -f client.mk
checkout", then a "make -f client.mk build".

Comment 12

[alanjstr]

Surely this testcase can be reduced more.  Does it need that Flash in it?  Maybe
it does, since I don't have Flash and I have yet to be able to make it crash.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031212
Firebird/0.7+

Comment 13

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Using the 2003-12-15-10-trunk/
mozilla-win32-svg-libart-mathml nightly, I also crash.

Comment 14

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Starting from a clean profile, it worked.  It broke when I installed flash click
to view: http://extensionroom.mozdev.org/more-info.php/flashclick

Resolving invalid and going to bother the mozdev people.

Comment 15

[Malcolm Rowe]

FWIW, I was also able to crash on 1.6a, but then I was also using the Flash
click-to-view extension :/

It may still be a bug in Gecko - reflow issues can be very timing- and
data-dependent.

Comment 16

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Created attachment 156009 [details]
minimized (?) testcase

Comment 17

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Reopening, as I can generate a testcase that includes a very cut-down binding
based on flashblock.

Comment 18

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Created attachment 156012 [details]
modified flashblock.jar

Comment 19

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Created attachment 156013 [details]
userContent.css

Comment 20

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

I added this:

  <RDF:Description RDF:about="urn:mozilla:package:flashblock"
                  
c:baseURL="jar:file:///C:/Documents%20and%20Settings/Chris/Application%20Data/Mozilla/Profiles/debug/yeo86u4k.slt/chrome/flashblock.jar!/content/flashblock/"
                   c:locType="profile"
                   c:displayName="Flash Click to View"
                   c:author="Ted Mielczarek"
                   c:authorURL="http://ted.mielczarek.org/code/mozilla/"
                   c:name="flashblock"
                   c:extension="true"
                   c:description="Replace Flash objects with a button you can
click to view them" />

and this:

  <RDF:Seq RDF:about="urn:mozilla:package:root">
    <RDF:li RDF:resource="urn:mozilla:package:flashblock"/>
    <RDF:li RDF:resource="urn:mozilla:package:autoscroll"/>
  </RDF:Seq>

to my chrome.rdf

Comment 21

[Boris Zbarsky [:bz] (vacation Aug 14-27)]

OK, so what seems to be happening here is the following (many thanks to shaver
for his patience and time in debugging this!):

1)  When constructing the <object>'s frame we enqueue the constructor execution
2)  When constructing the <input>'s frame, we end up calling ContentAppended on
    some anonymous content (called from nsTextControlFrame::InitEditor via some
    editor transaction stuff).  This causes us to process the attached queue
    before returning, which executes the constructor for the <object>.
3)  To execute the constructor we call WrapNative on the <object> to get a
    JSObject we can use as "this".  That ends up calling
    nsHTMLExternalObjSH::GetPluginInstance which calls
    FlushPendingNotifications.
4)  The flush causes a reflow, which tries to reflow a bogus frame tree (table
    cell frame has no inner block and inits an nsHTMLReflowState with a null
    frame) and hence crashes.  I'm not sure whence the bogosity arises exactly,
    but we're probably ending up notifying twice for the same content, reflowing
    while in the middle of frame construction, and all that jazz.

What I think should be done to fix this:

1)  Add asserts to nsCSSFrameConstructor to ensure that we are not reentering
    frame construction as we are here.
2)  Change nsTextControlFrame to init its editor off an event so we don't
    reenter in this case.
3)  Change nsDocument::FlushPendingNotifications to check whether it's safe to
    flush presshells before flushing (see code in
    nsHTMLDocument::FlushPendingNotifications to see how it works).  Change
    PresShell::IsSafeToFlush to say "no" while we're calling into the frame
    constructor.  This way we can't flush during frame construction.

Chances are, either #2 or #3 on its own will fix this bug, but I think it's
better to do both -- #2 will keep us from triggering the asserts from #1 and
running constructors at the wrong time, and #3 is good insurance in general.

Comment 22

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

I'm working on Item The First, but wanted to share roc's thought from IRC here,
for posterity and such:

< rocWork> I don't know enough about XBL to know whether the binding
attachment can be moved after the frame insertion. That would resolve the
problem completely.

Comment 23

[Boris Zbarsky [:bz] (vacation Aug 14-27)]

Doing that should be safe (as in, "try on trunk" safe, not "do on branch" safe),
in my opinion.  I agree that that's also worth doing.

Comment 24

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Created attachment 157841 [details] [diff] [review]
Item 1: protect against recursive frame construction

Comment 25

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Created attachment 157842 [details] [diff] [review]
item 2: asynchronous initialize editor to avoid re-entering frame construction

Most of the ReallyInitEditor changes are just indentation changes resulting
from the voidification of it (no way to prop failure to real caller anyway,
so...).  I can post a -w diff if that's easier to edit.

Comment 26

[Boris Zbarsky [:bz] (vacation Aug 14-27)]

Comment on attachment 157841 [details] [diff] [review]
Item 1: protect against recursive frame construction

st=bzbarsky, but on trunk make that a PRPackedBool coming right after
mQuotesDirty.

Comment 27

[Boris Zbarsky [:bz] (vacation Aug 14-27)]

Comment on attachment 157842 [details] [diff] [review]
item 2: asynchronous initialize editor to avoid re-entering frame construction

r=bzbarsky.  Note that the setup we have right now for deferring init of editor
to after anonymous content construction is no longer needed if we're putting it
off on an event.

Comment 28

[David Baron :dbaron: ⌚️UTC-7]

Comment on attachment 157842 [details] [diff] [review]
item 2: asynchronous initialize editor to avoid re-entering frame construction

sr=dbaron assuming the big reindented chunk doesn't change anything that would
surprise me (i.e, anything other than removing return values from returns). 
Use diff -b to check :-)

Also, should ReallyInitEditor be private, perhaps?  (It would require making
the callback functions friends.)

Comment 29

[David Baron :dbaron: ⌚️UTC-7]

Comment on attachment 157842 [details] [diff] [review]
item 2: asynchronous initialize editor to avoid re-entering frame construction

... although as bz points out, you should probably at least fix the comment at
the beginning of ReallyInitEditor and perhaps add an "XXX" comment that we
should simplify the existing code.

Comment 30

[David Baron :dbaron: ⌚️UTC-7]

Comment on attachment 157841 [details] [diff] [review]
Item 1: protect against recursive frame construction

r=dbaron, although this actually scares me a little bit for branches.  Or do we
know that this would always produce bad results now?

Comment 31

[Adam Hauner]

*** Bug 258178 has been marked as a duplicate of this bug. ***

Comment 32

[Adam Hauner]

Is topcrash bug 243528 dupe of this? It has same stacktrace, minimal testcase
attached. 

Comment 33

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

*** Bug 243528 has been marked as a duplicate of this bug. ***

Comment 34

[Laurens Blankers]

*** Bug 258313 has been marked as a duplicate of this bug. ***

Comment 35

[chris hofmann]

let's get this on the aviary and 1.7 branches...

Comment 36

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

dbaron: do we really want ReallyInitEditor private, rather than protected?  (The
event callback already is a friend in the posted patch.)

Comment 37

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Created attachment 161079 [details] [diff] [review]
item 2 v2: asynchronously initialize editor to avoid re-entering frame construction

With comment changes; this is what I committed to Aviary branch.  I'll pull a
1.7 tree later and see if it fits in there; bz said it doesn't go so well on
the trunk.  (But maybe for the trunk we should go whole-hog and rip out the
vestigial deferred-init code anyway?)

Comment 38

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Marking fixed-aviary1.0, but leaving it open for the rest of the work here to
happen on the trunk.

Comment 39

[Boris Zbarsky [:bz] (vacation Aug 14-27)]

Mike, if you can rip out the vestigial stuff on trunk, that would be great.

I believe your item 2 did apply to trunk, though; it was item 1 that did not
(and it was only slightly rotted).

Comment 40

[David Baron :dbaron: ⌚️UTC-7]

Oh, I just said private rather than protected since I'm a little skeptical about
whether this can be subclassed.

Comment 41

[Peter van der Woude [:Peter6]]

(In reply to comment #38)
> Marking fixed-aviary1.0, but leaving it open for the rest of the work here to
> happen on the trunk.

could bug 263060 be a regression of this patch ?

Comment 42

[Boris Zbarsky [:bz] (vacation Aug 14-27)]

> could bug 263060 be a regression of this patch ?

Absolutely.  Calling select() should force editor init.

Comment 43

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Fix committed to 1.7 branch, including update for 263060.  Simple application of

https://bugzilla.mozilla.org/attachment.cgi?id=161079&action=view
and
https://bugzilla.mozilla.org/attachment.cgi?id=161508&action=view
in order, not even any fuzz!

Comment 44

[Johnny Stenback (:jst)]

Looks like this caused regression bug 267352.

Comment 45

[Boris Zbarsky [:bz] (vacation Aug 14-27)]

This probably caused bug 267225 too -- we may need to block onload until that
editor-init event fires or something...

Comment 46

[Asa Dotzler [:asa]]

At the aviary meeting today, we decided we need to back this change out for the
Firefox 1.0 release.

Comment 47

[Johnny Stenback (:jst)]

This was backed out from the aviary branch due to the regression that was
introduced by this checkin.

Comment 48

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Can the crash be prevented with only part of the patch (without causing
regressions)?

Comment 49

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

This is still fixed on the trunk, AFAIK, so I think we want to leave this as FIXED.

Comment 50

[Bill Mason]

*** Bug 270824 has been marked as a duplicate of this bug. ***

Comment 51

[Mike Kaply [:mkaply]]

Argh. If this was backed out of Firefox 1.0, it needs to be backed out on the
1.7 branch as well.

Comment 52

[Boris Zbarsky [:bz] (vacation Aug 14-27)]

I'm going to reopen this.  I see no indication that this was ever checked in on
trunk....

Comment 53

[Leon Sha]

(In reply to comment #51)
> Argh. If this was backed out of Firefox 1.0, it needs to be backed out on the
> 1.7 branch as well.

Can anyone help to back it out on 1.7 branch?

Comment 54

[Mike Kaply [:mkaply]]

The exact backout:

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=AVIARY_1_0_20040515_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-11-04+21%3A00&maxdate=2004-11-04+21%3A10&cvsroot=%2Fcvsroot

Comment 55

[Johnny Stenback (:jst)]

Backed out of the 1.7 branch.

Comment 56

[timeless]

fixed1.7.5 designates the code in a specific release unless we respin 1.7.5
which we won't do, you can't change what code is in that. restoring keyword.

Comment 57

[Matthias Versen [:Matti]]

*** Bug 291306 has been marked as a duplicate of this bug. ***

Comment 58

[Olivier Cahagne]

*** Bug 291923 has been marked as a duplicate of this bug. ***

Comment 59

[Matthias Versen [:Matti]]

*** Bug 293533 has been marked as a duplicate of this bug. ***

Comment 60

[Jay Patel [:jay]]

*** Bug 294004 has been marked as a duplicate of this bug. ***

Comment 61

[Jay Patel [:jay]]

This crash has spiked in Firefox 1.0.3 and 1.0.4 Talkback data and migth be
worth revisiting if we have time.  It's currently the #19 topcrash for 1.0.4,
and does not exist in current Trunk or Deer Park Alpha 1 Talkback data:
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=1&searchby=stacksig&match=contains&searchfor=nsHTMLReflowState%3A%3AInit&vendor=All&product=All&platform=All&buildid=&sdate=&stime=&edate=&etime=&sortby=bbid

Are we sure this wasn't checked into the Trunk?  Or if some other checkin fixed
this crash?

Adding topcrash info for future reference, but that doesn't mean we can't
consider a fix for a future Aviary branch release (since this is somewhat of a
regression).

Here is a recent crash from 1.0.4:
Incident ID: 6467109
Stack Signature	nsHTMLReflowState::Init 780af5ee
Product ID	Firefox10
Build ID	2005051112
Trigger Time	2005-06-07 10:32:58.0
Platform	Win32
Operating System	Windows NT 5.0 build 2195
Module	firefox.exe + (0027a7f3)
URL visited	http://techreport.com/onearticle.x/8415
User Comments	opened the techreport webpage through a middle click (background
tab open) from www.nvnews.net. Not the first time FireFox crashes trying to open
techreport.com webpages...
Since Last Crash	45 sec
Total Uptime	45 sec
Trigger Reason	Access violation
Source File, Line No.
d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsHTMLReflowState.cpp,
line 326
Stack Trace 	
nsHTMLReflowState::Init 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsHTMLReflowState.cpp,
line 326]
nsHTMLReflowState::nsHTMLReflowState 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsHTMLReflowState.cpp,
line 221]
nsTableCellFrame::Reflow 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/table/src/nsTableCellFrame.cpp,
line 871]
nsContainerFrame::ReflowChild 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsContainerFrame.cpp,
line 982]
nsTableRowFrame::IR_TargetIsChild 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/table/src/nsTableRowFrame.cpp,
line 1229]
nsTableRowFrame::IncrementalReflow 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/table/src/nsTableRowFrame.cpp,
line 1113]
nsTableRowFrame::Reflow 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/table/src/nsTableRowFrame.cpp,
line 1401]
nsContainerFrame::ReflowChild 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsContainerFrame.cpp,
line 982]
nsTableRowGroupFrame::IR_TargetIsChild 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/table/src/nsTableRowGroupFrame.cpp,
line 1697]
nsTableRowGroupFrame::IncrementalReflow 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/table/src/nsTableRowGroupFrame.cpp,
line 1375]
nsTableRowGroupFrame::Reflow 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/table/src/nsTableRowGroupFrame.cpp,
line 1281]
nsContainerFrame::ReflowChild 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsContainerFrame.cpp,
line 982]
nsTableFrame::IR_TargetIsChild 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/table/src/nsTableFrame.cpp,
line 2978]
nsTableFrame::IncrementalReflow 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/table/src/nsTableFrame.cpp,
line 2687]
nsTableFrame::Reflow 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/table/src/nsTableFrame.cpp,
line 1953]
nsContainerFrame::ReflowChild 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsContainerFrame.cpp,
line 982]
nsTableOuterFrame::OuterReflowChild 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/table/src/nsTableOuterFrame.cpp,
line 1335]
nsTableOuterFrame::IR_InnerTableReflow 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/table/src/nsTableOuterFrame.cpp,
line 1695]
nsTableOuterFrame::IR_TargetIsInnerTableFrame 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/table/src/nsTableOuterFrame.cpp,
line 1449]
nsTableOuterFrame::IR_TargetIsChild 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/table/src/nsTableOuterFrame.cpp,
line 1431]
nsTableOuterFrame::IncrementalReflow 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/table/src/nsTableOuterFrame.cpp,
line 1400]
nsTableOuterFrame::Reflow 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/table/src/nsTableOuterFrame.cpp,
line 1957]
nsBlockReflowContext::ReflowBlock 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsBlockReflowContext.cpp,
line 547]
nsBlockFrame::ReflowBlockFrame 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsBlockFrame.cpp,
line 3068]
nsBlockFrame::ReflowLine 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsBlockFrame.cpp,
line 2334]
nsBlockFrame::ReflowDirtyLines 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsBlockFrame.cpp,
line 2098]
nsBlockFrame::Reflow 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsBlockFrame.cpp,
line 817]
nsBlockReflowContext::ReflowBlock 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsBlockReflowContext.cpp,
line 547]
nsBlockFrame::ReflowBlockFrame 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsBlockFrame.cpp,
line 3068]
nsBlockFrame::ReflowLine 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsBlockFrame.cpp,
line 2334]
nsBlockFrame::ReflowDirtyLines 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsBlockFrame.cpp,
line 2098]
nsBlockFrame::Reflow 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsBlockFrame.cpp,
line 817]
nsContainerFrame::ReflowChild 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsContainerFrame.cpp,
line 982]
CanvasFrame::Reflow 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsHTMLFrame.cpp,
line 554]
nsBoxToBlockAdaptor::Reflow 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/xul/base/src/nsBoxToBlockAdaptor.cpp,
line 884]
nsBoxToBlockAdaptor::DoLayout 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/xul/base/src/nsBoxToBlockAdaptor.cpp,
line 626]
nsBox::Layout 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/xul/base/src/nsBox.cpp,
line 1016]
nsBox::Layout 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/xul/base/src/nsBox.cpp,
line 1016]
nsGfxScrollFrameInner::LayoutBox 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsGfxScrollFrame.cpp,
line 1264]
nsGfxScrollFrame::DoLayout 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsGfxScrollFrame.cpp,
line 1273]
nsBox::Layout 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/xul/base/src/nsBox.cpp,
line 1016]
nsGfxScrollFrame::Reflow 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsGfxScrollFrame.cpp,
line 873]
nsContainerFrame::ReflowChild 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsContainerFrame.cpp,
line 982]
ViewportFrame::Reflow 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsViewportFrame.cpp,
line 249]
IncrementalReflow::Dispatch 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsPresShell.cpp,
line 904]
PresShell::ProcessReflowCommands 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsPresShell.cpp,
line 6401]
PresShell::FlushPendingNotifications 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsPresShell.cpp,
line 5114]
nsDocument::FlushPendingNotifications 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/base/src/nsDocument.cpp,
line 3975]
nsHTMLDocument::FlushPendingNotifications 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/html/document/src/nsHTMLDocument.cpp,
line 1357]
nsHTMLExternalObjSH::GetPluginInstance 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/dom/src/base/nsDOMClassInfo.cpp,
line 6710]
nsHTMLExternalObjSH::PostCreate 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/dom/src/base/nsDOMClassInfo.cpp,
line 6770]
XPCWrappedNative::GetNewOrUsed 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp,
line 438]
XPCConvert::NativeInterface2JSObject 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcconvert.cpp,
line 1065]
nsXPConnect::WrapNative 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/nsXPConnect.cpp,
line 570]
nsXBLPrototypeHandler::ExecuteHandler 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xbl/src/nsXBLPrototypeHandler.cpp,
line 420]
nsXBLPrototypeHandler::BindingDetached 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xbl/src/nsXBLPrototypeHandler.cpp,
line 535]
nsXBLBinding::ExecuteAttachedHandler 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xbl/src/nsXBLBinding.cpp,
line 854]
nsBindingManager::ProcessAttachedQueue 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xbl/src/nsBindingManager.cpp,
line 943]
nsCSSFrameConstructor::ContentAppended 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp,
line 8334]
PresShell::ContentAppended 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsPresShell.cpp,
line 5221]
nsHTMLDocument::ContentAppended 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/html/document/src/nsHTMLDocument.cpp,
line 1201]
nsGenericElement::InsertChildAt 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/base/src/nsGenericElement.cpp,
line 2522]
nsGenericElement::doInsertBefore 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/base/src/nsGenericElement.cpp,
line 2888]
nsHTMLFontElement::InsertBefore 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/html/content/src/nsHTMLFontElement.cpp,
line 63]

Comment 62

[Matthias Versen [:Matti]]

*** Bug 297479 has been marked as a duplicate of this bug. ***

Comment 63

[Kevin Brosnan]

*** Bug 298207 has been marked as a duplicate of this bug. ***

Comment 64

[Vincent Lefevre]

*** Bug 297686 has been marked as a duplicate of this bug. ***

Comment 65

[timeless]

*** Bug 304796 has been marked as a duplicate of this bug. ***

Comment 66

[Adam Guthrie]

*** Bug 305193 has been marked as a duplicate of this bug. ***

Comment 67

[Adam Guthrie]

*** Bug 312906 has been marked as a duplicate of this bug. ***

Comment 68

[Adam Guthrie]

*** Bug 318255 has been marked as a duplicate of this bug. ***

Comment 69

[Ian Batterbee]

I believe bug 350966 is a dupe of this one - the reduced testcase for this bug causes the same crash I'm seeing in my own (more) reduced testcase in 350966.

I'm seeing this in a fresh moz 1.7.14 with only flashblock 1.3.4 installed.

Comment 70

[Ian Batterbee]

*** Bug 350966 has been marked as a duplicate of this bug. ***

Comment 71

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Mass abdication.

Comment 72

[Boris Zbarsky [:bz] (vacation Aug 14-27)]

Is this still a problem now that bug 267833 is fixed?

Comment 73

[AndrewM]

I don't get a crash from either of the testcases.

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a9pre) Gecko/2007101605 Minefield/3.0a9pre ID:2007101605

Comment 74

[Wayne Mery (:wsmwk, NI for questions)]

WFM  attachment 156009 [details], attachment 137465 [details]
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b2pre) Gecko/2007110805 Minefield/3.0b2pre
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b2pre) Gecko/2007112702 SeaMonkey/2.0a1pre

Comment 75

[Samuel Sidler (old account; do not CC)]

Resolving as WFM. Chris, if you can still reproduce, please reopen.