Closed Bug 228557 Opened 22 years ago Closed 18 years ago

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

Categories

(Core :: Layout, defect)

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: 22 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.
Attached file minimized (?) testcase —
Attachment #137465 - Attachment is obsolete: true
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: 22 years ago → 21 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: 21 years ago → 18 years ago
Resolution: --- → WORKSFORME
Crash Signature: [@ nsHTMLReflowState::Init]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: