Closed Bug 228557 Opened 17 years ago Closed 12 years ago

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

Categories

(Core :: Layout, defect, critical)

Product:
Core
Component:
Layout
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: csthomas, Unassigned)

References

(
URL
)

Details

(Keywords: crash, fixed1.7.5, topcrash+)

Crash Data

Attachments

(7 files, 2 obsolete files)

Call stack
35.87 KB, text/plain
Details
New call stack
39.88 KB, text/plain
Details
minimized (?) testcase
300 bytes, text/html
Details
modified flashblock.jar
1.03 KB, application/jar
Details
userContent.css
159 bytes, text/css
Details
Item 1: protect against recursive frame construction
4.72 KB, patch
dbaron
: review+
bzbarsky
: superreview+
Details | Diff | Splinter Review
item 2 v2: asynchronously initialize editor to avoid re-entering frame construction
6.59 KB, patch
Details | Diff | Splinter Review 
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
WFM, 20031211, Windows XP
Summary: Crash on provided URL → Crash on provided URL [@ nsHTMLReflowState::Init]
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".
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 -->');
Hmm, that URL is returning something different now :(
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.
> 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?
> 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).
Attached file Reduced testcase (obsolete) — 
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.
Keywords: crash
Attached file 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
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".
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+
Using the 2003-12-15-10-trunk/
mozilla-win32-svg-libart-mathml nightly, I also crash.
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.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → INVALID
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.
Reopening, as I can generate a testcase that includes a very cut-down binding
based on flashblock.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
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
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
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.

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.
Assignee: core.layout → shaver
Status: NEW → ASSIGNED
Attachment #157841 - Flags: superreview?(bzbarsky)
Attachment #157841 - Flags: review?(dbaron)
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 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.
Attachment #157841 - Flags: superreview?(bzbarsky) → superreview+
Attachment #157842 - Flags: superreview?(dbaron)
Attachment #157842 - Flags: review?(bzbarsky)
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.
Attachment #157842 - Flags: review?(bzbarsky) → review+
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.)
Attachment #157842 - Flags: superreview?(dbaron) → superreview+
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 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?
Attachment #157841 - Flags: review?(dbaron) → review+
*** Bug 258178 has been marked as a duplicate of this bug. ***
Is topcrash bug 243528 dupe of this? It has same stacktrace, minimal testcase
attached. 
*** Bug 243528 has been marked as a duplicate of this bug. ***
Blocks: 257818
*** Bug 258313 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.0?
let's get this on the aviary and 1.7 branches...
Flags: blocking-aviary1.0? → blocking-aviary1.0+
dbaron: do we really want ReallyInitEditor private, rather than protected?  (The
event callback already is a friend in the posted patch.)
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?)
Attachment #157842 - Attachment is obsolete: true
Marking fixed-aviary1.0, but leaving it open for the rest of the work here to
happen on the trunk.
Keywords: fixed-aviary1.0
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).
Oh, I just said private rather than protected since I'm a little skeptical about
whether this can be subclassed.
(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 ?

> could bug 263060 be a regression of this patch ?

Absolutely.  Calling select() should force editor init.
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!
Keywords: fixed1.7.x
Looks like this caused regression bug 267352.
This probably caused bug 267225 too -- we may need to block onload until that
editor-init event fires or something...
Depends on: 267225, 267352
At the aviary meeting today, we decided we need to back this change out for the
Firefox 1.0 release.
This was backed out from the aviary branch due to the regression that was
introduced by this checkin.
Flags: blocking-aviary1.0+
Keywords: fixed-aviary1.0
Can the crash be prevented with only part of the patch (without causing
regressions)?
This is still fixed on the trunk, AFAIK, so I think we want to leave this as FIXED.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago → 16 years ago
Resolution: --- → FIXED
*** Bug 270824 has been marked as a duplicate of this bug. ***
Argh. If this was backed out of Firefox 1.0, it needs to be backed out on the
1.7 branch as well.
I'm going to reopen this.  I see no indication that this was ever checked in on
trunk....
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
No longer depends on: 267225
(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?
Backed out of the 1.7 branch.
Keywords: fixed1.7.5
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.
Keywords: fixed1.7.5
*** Bug 291306 has been marked as a duplicate of this bug. ***
*** Bug 291923 has been marked as a duplicate of this bug. ***
*** Bug 293533 has been marked as a duplicate of this bug. ***
*** Bug 294004 has been marked as a duplicate of this bug. ***
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]
Keywords: topcrash+
Summary: Crash on provided URL [@ nsHTMLReflowState::Init] → M17x FF104 Crash on provided URL [@ nsHTMLReflowState::Init]
*** Bug 297479 has been marked as a duplicate of this bug. ***
*** Bug 298207 has been marked as a duplicate of this bug. ***
*** Bug 297686 has been marked as a duplicate of this bug. ***
*** Bug 304796 has been marked as a duplicate of this bug. ***
*** Bug 305193 has been marked as a duplicate of this bug. ***
*** Bug 312906 has been marked as a duplicate of this bug. ***
*** Bug 318255 has been marked as a duplicate of this bug. ***
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.



*** Bug 350966 has been marked as a duplicate of this bug. ***
Depends on: 346094
Mass abdication.
Assignee: shaver → nobody
Status: REOPENED → NEW
Is this still a problem now that bug 267833 is fixed?
Depends on: 267833
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
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
Resolving as WFM. Chris, if you can still reproduce, please reopen.
Status: NEW → RESOLVED
Closed: 16 years ago → 12 years ago
Resolution: --- → WORKSFORME
Crash Signature: [@ nsHTMLReflowState::Init]
You need to log in before you can comment on or make changes to this bug.