Closed
Bug 228557
Opened 21 years ago
Closed 17 years ago
M17x FF104 Crash on provided URL [@ nsHTMLReflowState::Init]
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: csthomas, Unassigned)
References
()
Details
(Keywords: crash, fixed1.7.5, topcrash+)
Crash Data
Attachments
(7 files, 2 obsolete files)
35.87 KB,
text/plain
|
Details | |
39.88 KB,
text/plain
|
Details | |
300 bytes,
text/html
|
Details | |
1.03 KB,
application/jar
|
Details | |
159 bytes,
text/css
|
Details | |
4.72 KB,
patch
|
dbaron
:
review+
bzbarsky
:
superreview+
|
Details | Diff | Splinter Review |
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
Reporter | ||
Comment 1•21 years ago
|
||
Comment 2•21 years ago
|
||
WFM, 20031211, Windows XP
Updated•21 years ago
|
Summary: Crash on provided URL → Crash on provided URL [@ nsHTMLReflowState::Init]
Reporter | ||
Comment 3•21 years ago
|
||
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".
Reporter | ||
Comment 4•21 years ago
|
||
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 -->');
Reporter | ||
Comment 5•21 years ago
|
||
Hmm, that URL is returning something different now :(
Comment 6•21 years ago
|
||
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.
Reporter | ||
Comment 7•21 years ago
|
||
> 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•21 years ago
|
||
> 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).
Reporter | ||
Comment 9•21 years ago
|
||
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.
Reporter | ||
Comment 10•21 years ago
|
||
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
Reporter | ||
Comment 11•21 years ago
|
||
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•21 years ago
|
||
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+
Reporter | ||
Comment 13•21 years ago
|
||
Using the 2003-12-15-10-trunk/ mozilla-win32-svg-libart-mathml nightly, I also crash.
Reporter | ||
Comment 14•21 years ago
|
||
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: 21 years ago
Resolution: --- → INVALID
Comment 15•21 years ago
|
||
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.
Reporter | ||
Comment 16•20 years ago
|
||
Attachment #137465 -
Attachment is obsolete: true
Reporter | ||
Comment 17•20 years ago
|
||
Reopening, as I can generate a testcase that includes a very cut-down binding based on flashblock.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Reporter | ||
Comment 18•20 years ago
|
||
Reporter | ||
Comment 19•20 years ago
|
||
Reporter | ||
Comment 20•20 years ago
|
||
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•20 years ago
|
||
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.
Comment 23•20 years ago
|
||
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 26•20 years ago
|
||
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 27•20 years ago
|
||
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+
Comment 31•20 years ago
|
||
*** Bug 258178 has been marked as a duplicate of this bug. ***
Comment 32•20 years ago
|
||
Is topcrash bug 243528 dupe of this? It has same stacktrace, minimal testcase attached.
Reporter | ||
Comment 33•20 years ago
|
||
*** Bug 243528 has been marked as a duplicate of this bug. ***
Comment 34•20 years ago
|
||
*** Bug 258313 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Flags: blocking-aviary1.0?
Comment 35•20 years ago
|
||
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
Comment 39•20 years ago
|
||
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.
Comment 41•20 years ago
|
||
(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•20 years ago
|
||
> 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
Comment 44•20 years ago
|
||
Looks like this caused regression bug 267352.
Comment 45•20 years ago
|
||
This probably caused bug 267225 too -- we may need to block onload until that editor-init event fires or something...
Comment 46•20 years ago
|
||
At the aviary meeting today, we decided we need to back this change out for the Firefox 1.0 release.
Comment 47•20 years ago
|
||
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
Reporter | ||
Comment 48•20 years ago
|
||
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: 21 years ago → 20 years ago
Resolution: --- → FIXED
Comment 50•20 years ago
|
||
*** Bug 270824 has been marked as a duplicate of this bug. ***
Comment 51•20 years ago
|
||
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•19 years ago
|
||
I'm going to reopen this. I see no indication that this was ever checked in on trunk....
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 53•19 years ago
|
||
(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•19 years ago
|
||
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 56•19 years ago
|
||
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
Comment 57•19 years ago
|
||
*** Bug 291306 has been marked as a duplicate of this bug. ***
Comment 58•19 years ago
|
||
*** Bug 291923 has been marked as a duplicate of this bug. ***
Comment 59•19 years ago
|
||
*** Bug 293533 has been marked as a duplicate of this bug. ***
Comment 60•19 years ago
|
||
*** Bug 294004 has been marked as a duplicate of this bug. ***
Comment 61•19 years ago
|
||
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]
Comment 62•19 years ago
|
||
*** Bug 297479 has been marked as a duplicate of this bug. ***
Comment 63•19 years ago
|
||
*** Bug 298207 has been marked as a duplicate of this bug. ***
Comment 64•19 years ago
|
||
*** Bug 297686 has been marked as a duplicate of this bug. ***
Comment 65•19 years ago
|
||
*** Bug 304796 has been marked as a duplicate of this bug. ***
Comment 66•19 years ago
|
||
*** Bug 305193 has been marked as a duplicate of this bug. ***
Comment 67•19 years ago
|
||
*** Bug 312906 has been marked as a duplicate of this bug. ***
Comment 68•19 years ago
|
||
*** Bug 318255 has been marked as a duplicate of this bug. ***
Comment 69•18 years ago
|
||
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•18 years ago
|
||
*** Bug 350966 has been marked as a duplicate of this bug. ***
Mass abdication.
Assignee: shaver → nobody
Status: REOPENED → NEW
Comment 72•17 years ago
|
||
Is this still a problem now that bug 267833 is fixed?
Comment 73•17 years ago
|
||
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•17 years ago
|
||
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•17 years ago
|
||
Resolving as WFM. Chris, if you can still reproduce, please reopen.
Status: NEW → RESOLVED
Closed: 20 years ago → 17 years ago
Resolution: --- → WORKSFORME
Assignee | ||
Updated•13 years ago
|
Crash Signature: [@ nsHTMLReflowState::Init]
You need to log in
before you can comment on or make changes to this bug.
Description
•