Closed
Bug 228557
Opened 22 years ago
Closed 18 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•22 years ago
|
||
Comment 2•22 years ago
|
||
WFM, 20031211, Windows XP
Updated•22 years ago
|
Summary: Crash on provided URL → Crash on provided URL [@ nsHTMLReflowState::Init]
Reporter | ||
Comment 3•22 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•22 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•22 years ago
|
||
Hmm, that URL is returning something different now :(
Comment 6•22 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•22 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•22 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•22 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•22 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•22 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•22 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•22 years ago
|
||
Using the 2003-12-15-10-trunk/
mozilla-win32-svg-libart-mathml nightly, I also crash.
Reporter | ||
Comment 14•22 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: 22 years ago
Resolution: --- → INVALID
Comment 15•22 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•21 years ago
|
||
Attachment #137465 -
Attachment is obsolete: true
Reporter | ||
Comment 17•21 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•21 years ago
|
||
Reporter | ||
Comment 19•21 years ago
|
||
Reporter | ||
Comment 20•21 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•21 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
Comment 22•21 years ago
|
||
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•21 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.
Comment 24•21 years ago
|
||
Updated•21 years ago
|
Assignee: core.layout → shaver
Status: NEW → ASSIGNED
Updated•21 years ago
|
Attachment #157841 -
Flags: superreview?(bzbarsky)
Attachment #157841 -
Flags: review?(dbaron)
Comment 25•21 years ago
|
||
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•21 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+
Updated•21 years ago
|
Attachment #157842 -
Flags: superreview?(dbaron)
Attachment #157842 -
Flags: review?(bzbarsky)
![]() |
||
Comment 27•21 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•21 years ago
|
||
*** Bug 258178 has been marked as a duplicate of this bug. ***
Comment 32•21 years ago
|
||
Is topcrash bug 243528 dupe of this? It has same stacktrace, minimal testcase
attached.
Reporter | ||
Comment 33•21 years ago
|
||
*** Bug 243528 has been marked as a duplicate of this bug. ***
Comment 34•21 years ago
|
||
*** Bug 258313 has been marked as a duplicate of this bug. ***
Updated•21 years ago
|
Flags: blocking-aviary1.0?
Comment 35•21 years ago
|
||
let's get this on the aviary and 1.7 branches...
Flags: blocking-aviary1.0? → blocking-aviary1.0+
Comment 36•21 years ago
|
||
dbaron: do we really want ReallyInitEditor private, rather than protected? (The
event callback already is a friend in the posted patch.)
Comment 37•21 years ago
|
||
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
Comment 38•21 years ago
|
||
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•21 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•21 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•21 years ago
|
||
> could bug 263060 be a regression of this patch ?
Absolutely. Calling select() should force editor init.
Comment 43•21 years ago
|
||
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•21 years ago
|
||
Looks like this caused regression bug 267352.
![]() |
||
Comment 45•21 years ago
|
||
This probably caused bug 267225 too -- we may need to block onload until that
editor-init event fires or something...
Comment 46•21 years ago
|
||
At the aviary meeting today, we decided we need to back this change out for the
Firefox 1.0 release.
Comment 47•21 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•21 years ago
|
||
Can the crash be prevented with only part of the patch (without causing
regressions)?
Comment 49•21 years ago
|
||
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
Comment 50•21 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•20 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•20 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•20 years ago
|
||
Comment 56•20 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•20 years ago
|
||
*** Bug 291306 has been marked as a duplicate of this bug. ***
Comment 58•20 years ago
|
||
*** Bug 291923 has been marked as a duplicate of this bug. ***
Comment 59•20 years ago
|
||
*** Bug 293533 has been marked as a duplicate of this bug. ***
Comment 60•20 years ago
|
||
*** Bug 294004 has been marked as a duplicate of this bug. ***
Comment 61•20 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•20 years ago
|
||
*** Bug 297479 has been marked as a duplicate of this bug. ***
Comment 63•20 years ago
|
||
*** Bug 298207 has been marked as a duplicate of this bug. ***
Comment 64•20 years ago
|
||
*** Bug 297686 has been marked as a duplicate of this bug. ***
Comment 65•20 years ago
|
||
*** Bug 304796 has been marked as a duplicate of this bug. ***
Comment 66•20 years ago
|
||
*** Bug 305193 has been marked as a duplicate of this bug. ***
Comment 67•20 years ago
|
||
*** Bug 312906 has been marked as a duplicate of this bug. ***
Comment 68•20 years ago
|
||
*** Bug 318255 has been marked as a duplicate of this bug. ***
Comment 69•19 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•19 years ago
|
||
*** Bug 350966 has been marked as a duplicate of this bug. ***
![]() |
||
Comment 72•18 years ago
|
||
Is this still a problem now that bug 267833 is fixed?
Comment 73•18 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•18 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•18 years ago
|
||
Resolving as WFM. Chris, if you can still reproduce, please reopen.
Status: NEW → RESOLVED
Closed: 21 years ago → 18 years ago
Resolution: --- → WORKSFORME
Assignee | ||
Updated•14 years ago
|
Crash Signature: [@ nsHTMLReflowState::Init]
You need to log in
before you can comment on or make changes to this bug.
Description
•