Closed
Bug 244454
Opened 20 years ago
Closed 20 years ago
Browser crashes in [@ nsBlockFrame::ReflowFloat] when visiting that page
Categories
(Core :: Layout, defect, P2)
Tracking
()
VERIFIED
FIXED
mozilla1.8alpha2
People
(Reporter: joh_walt, Assigned: dbaron)
References
()
Details
(Keywords: crash, qawanted, testcase, Whiteboard: [patch])
Crash Data
Attachments
(3 files, 6 obsolete files)
370 bytes,
text/html
|
Details | |
4.39 KB,
text/plain
|
Details | |
10.35 KB,
patch
|
roc
:
review+
roc
:
superreview+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a1) Gecko/20040520 Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a1) Gecko/20040520 When visiting the above URL and the page has loaded Mozilla crashes each time. I tested this on Windows 98 and Linux. JavaScript has to be activated, I have no Plugins installed. Reproducible: Always Steps to Reproduce: 1. Make sure JavaScript for browser is on 2. Type URL and enter 3. Wait until the page has loaded Actual Results: Crash Expected Results: Don't crash MOZILLA verursachte einen Fehler durch eine ungültige Seite in Modul <Unbekannt> bei 0000:0182968d. Register: EAX=00000000 CS=0167 EIP=0182968d EFLGS=00010282 EBX=0182d6a4 SS=016f ESP=0064eefc EBP=0064ef10 ECX=0182d6a4 DS=016f ESI=00000000 FS=133f EDX=018296c4 ES=016f EDI=0182d6a4 GS=0000 Bytes bei CS:EIP: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Stapelwerte: 60294079 00000000 01837398 0182db10 0182d6a4 0064ef3c 602940fe 01d889b0 01d6f9e0 01d6f9f8 0064f040 018f5b84 00000000 017ed644 01837398 01837398 Nothing on Linux, Mozilla just disappears.
Comment 1•20 years ago
|
||
I get the following assertions on load: ###!!! ASSERTION: Weird parent in ConstructTableForeignFrame: 'parentFrame == aState.mPseudoFrames.mCellInner.mFrame', file /home/bzbarsky/mozilla/xlib/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp, line 2982 ###!!! ASSERTION: RemovedAsPrimaryFrame called after PreDestroy: 'PR_FALSE', file /home/bzbarsky/mozilla/xlib/mozilla/layout/html/forms/src/nsTextControlFrame.cpp, line 1302 Followed by a crash due to calling GetStyleData on a deleted frame. It'd be very nice if someone could create a minimal testcase showing the crash...
Component: Browser-General → Layout
Keywords: crash
Updated•20 years ago
|
Comment 2•20 years ago
|
||
Confirming crash with trunk build 2004-05-23-07 on Windows XP. Full stacktrace coming as an attachment.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 3•20 years ago
|
||
Comment 4•20 years ago
|
||
I stripped everything from the URL which wasn't needed to remain the crash. The testcase crashes Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040522 Firefox/0.8.0+
Updated•20 years ago
|
Attachment #149166 -
Attachment mime type: text/plain → text/html
Comment 5•20 years ago
|
||
Well, maybe not very necessary anymore, but since I was busy with it, and it is a bit smaller than the other crash testcase I decided to upload it anyway. Crashes for me with: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 Firefox/0.8.0+
Updated•20 years ago
|
Summary: Browser crashes when visiting that page → Browser crashes in [@ nsBlockFrame::ReflowFloat] when visiting that page
Comment 6•20 years ago
|
||
also crashes windows 1.7rc2 : TB57883G
Flags: blocking1.7?
Keywords: testcase
Updated•20 years ago
|
OS: other → Windows 98
Hardware: Other → PC
Comment 7•20 years ago
|
||
Actually, could someone grab the JS files too and see whether you can remove anything from those? And whether you can inline them, for that matter? It looks like the second JS file is somehow triggering a bug in our frame construction code that makes everything else break. Note that the exact crash location will sorta depend on when you end up first referencing deleted memory, so the signature in the summary is likely not the only one this bug will show...
Comment 8•20 years ago
|
||
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a2) Gecko/20040523 Talkback TB58111W on this minimized local copy: <HTML><HEAD></HEAD><BODY> <A><BLINK><FONT size=1><CENTER> <SCRIPT type=text/javascript> document.write ("<script src='http://www.davisind.com/banner3/adjs.php?n=123456789'><\/script>"); </SCRIPT> </CENTER> <SCRIPT type=text/javascript> document.write ("<script src='http://www.davisind.com/banner3/adjs.php?n=987654321&what=zone:10&exclude=123456789'><\/script>"); </SCRIPT> </BODY></HTML> All of these tags are needed, didn´t crash when I uncommented one: <A><BLINK><FONT size=1><CENTER> The </CENTER> must be between the scripts, no crash if moved past the seconf script. Other Talkbacks: TB57863K, TB57781X, TB57738X for your comfort, no crash: http://www.davisind.com/banner3/adjs.php?n=123456789 http://www.davisind.com/banner3/adjs.php?n=987654321&what=zone:10&exclude=123456789
Comment 9•20 years ago
|
||
Hermann, see comment 7. We know where and sorta why this crashes; what's not clear is what triggers the bogus frame construction.
Comment 10•20 years ago
|
||
unzip into a folder in your harddisk. 244454.html, 1f.js, 2f.js are created, each about 200 byte. start 244454.html, enjoy crash ;-)
Comment 11•20 years ago
|
||
TB58726G crash with local testcase http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB58726G Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a2) Gecko/20040523 <HTML><HEAD></HEAD><BODY> <A><BLINK><FONT size=1><CENTER> <SCRIPT type=text/javascript>document.write ("<script src='1f.js'><\/script>");</SCRIPT> </CENTER> <SCRIPT type=text/javascript>document.write ("<script src='2f.js'><\/script>");</SCRIPT> </BODY></HTML> file 1f.js: var ba = ''; ba += '<'+'div id="beacon_39" style="position: absolute; left: 0px; top: 0px; visibility: hidden;"><'+'/div>'; document.write(ba); file 2f.js: var ba = ''; ba += '<'+'table border="2" color="black" width="130" cellspacing="1" cellpadding="0">\n'; ba += '<'+'tr><'+'td width="143" align="center"><'+'/td>\n <'+'/tr>\n <'+'/table>\n'; document.write(ba);
Comment 12•20 years ago
|
||
TB59179H http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB59179H DoDeletingFrameSubtree 585be954 Access violation c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp, line 9103 js files can even be more reduced: var ba = ''; ba += '<'+'div style="position: absolute; left: 0px; top: 0px;"><'+'/div>'; document.write(ba); var ba = ''; ba += '<'+'table width="130"><'+'tr><'+'td><'+'/td><'+'/tr><'+'/table>'; document.write(ba);
Comment 13•20 years ago
|
||
In fact, you could even get rid of the intermediary variables in the JS files altogether. Also, does it matter whether you document.write a <script> or just document.write the div or table in the original HTML? That's the part I'm really interested in.... (and attach the result as an attachment, instead of pasting stuff into the bug). Also, it's not worth it to post stacks and talkback ids. See comment 7. They're just noise.
Comment 14•20 years ago
|
||
Updated•20 years ago
|
Attachment #149166 -
Attachment is obsolete: true
Comment 15•20 years ago
|
||
I further removed unneeded things from Hermann's code and encountered something perhaps interesting. With position:absolute and position:fixed the testcase leads to a crash, but with position:relative nothing happens.
Comment 16•20 years ago
|
||
(In reply to comment #13) document.write without a <script> and a extern .js file as src doesn't crash.
Comment 17•20 years ago
|
||
This inlines all the scripts (using data: URIs; just putting them directly inline doesn't work), removes the <a> and <blink> in favor of <span>, and replaces <center> with <div>. It looks like the two nested ib splits, the residual style, and the document.written external scripts are necessary... I'll try to look into this tomorrow afternoon/evening.
Attachment #149165 -
Attachment is obsolete: true
Attachment #149167 -
Attachment is obsolete: true
Attachment #149213 -
Attachment is obsolete: true
Attachment #149251 -
Attachment is obsolete: true
Attachment #149252 -
Attachment is obsolete: true
Comment 18•20 years ago
|
||
bz, does it look like it might be a straight forward fix, or complicated?
Updated•20 years ago
|
Attachment #149288 -
Attachment is patch: false
Attachment #149288 -
Attachment mime type: text/plain → text/html
Comment 19•20 years ago
|
||
Hard to tell. We're crashing under DoDeletingFrameSubtree because the outOfFlowFrame we get is already destroyed, so we die when calling GetStyleData on it. Earlier up, we seem to have a <span> as a float containing block, so things are already pretty broken at that point...
Comment 20•20 years ago
|
||
Note that I tried to wallpaper over this by adding: ((nsPlaceholderFrame*)childFrame)->SetOutOfFlowFrame(nsnull); when we enqueue the out-of-flow frame for destruction in DoDeletingFrameSubtree, but we still crash. Also note that my stack is not under ReflowFloat -- I crash under WipeContainingBlock, called from ContentAppended, etc, when appending to the <font>. The multiple IB splits here suck. :(
Assignee | ||
Comment 21•20 years ago
|
||
Marking blocking1.7+, although this is at risk for being minused, since we're hoping to ship early next week.
Flags: blocking1.7? → blocking1.7+
Assignee | ||
Comment 22•20 years ago
|
||
This is a stack from the crash in attachment 149288 [details], with some additional
comments based on examining some frames in the debugger.
I think the cause of the problem is that WipeContainingBlock is being asked to
wipe an inline rather than a block (frame 20). Does that make sense?
Assignee | ||
Comment 23•20 years ago
|
||
What's happening is that in ContentAppended, |containingBlock| is the anonymous block for the inline element that already contains a block. When we call |ContentReplaced|, that's the inline, so we end up going back another level. I think the fix involves making sure to walk up further if we have a :-moz-anonymous-block.
Assignee | ||
Comment 24•20 years ago
|
||
I think any fix here will be too risky for the branch at this point. This crash is just on one site, as far as we know.
Flags: blocking1.7+ → blocking1.7-
Assignee | ||
Comment 25•20 years ago
|
||
Assignee: nobody → dbaron
Status: NEW → ASSIGNED
Assignee | ||
Updated•20 years ago
|
Priority: -- → P2
Whiteboard: [patch]
Target Milestone: --- → mozilla1.8alpha2
Assignee | ||
Updated•20 years ago
|
Attachment #150223 -
Flags: superreview?(roc)
Attachment #150223 -
Flags: review?(roc)
Attachment #150223 -
Flags: superreview?(roc)
Attachment #150223 -
Flags: superreview+
Attachment #150223 -
Flags: review?(roc)
Attachment #150223 -
Flags: review+
Assignee | ||
Comment 26•20 years ago
|
||
Fix checked in to trunk, 2004-06-17 11:51 -0700.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Verified FIXED with build 2004-06-30-08 on Windows XP.
Status: RESOLVED → VERIFIED
Comment 28•20 years ago
|
||
*** Bug 271338 has been marked as a duplicate of this bug. ***
Updated•13 years ago
|
Crash Signature: [@ nsBlockFrame::ReflowFloat]
You need to log in
before you can comment on or make changes to this bug.
Description
•