Last Comment Bug 244454 - Browser crashes in [@ nsBlockFrame::ReflowFloat] when visiting that page
: Browser crashes in [@ nsBlockFrame::ReflowFloat] when visiting that page
: crash, qawanted, testcase
Product: Core
Classification: Components
Component: Layout (show other bugs)
: Trunk
: x86 Windows 98
: P2 critical (vote)
: mozilla1.8alpha2
Assigned To: David Baron :dbaron: ⌚️UTC-10
: Jet Villegas (:jet)
: 271338 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2004-05-23 14:01 PDT by Johannes Walther
Modified: 2011-06-13 10:01 PDT (History)
10 users (show)
dbaron: blocking1.7-
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

TB57828W (8.66 KB, text/plain)
2004-05-23 16:19 PDT, Stephen Donner [:stephend]
no flags Details
Testcase for crash (1.23 KB, text/html)
2004-05-23 16:23 PDT, Bruno 'Aqualon' Escherl
no flags Details
Another small crash testcase, a little smaller (476 bytes, text/html)
2004-05-23 16:31 PDT, Martijn Wargers [:mwargers] (not working for Mozilla)
no flags Details
700 byte zipped testcase, local (709 bytes, application/zip)
2004-05-24 09:13 PDT, Hermann Schwab
no flags Details
crash testcase with position:absolute (495 bytes, application/x-zip-compressed)
2004-05-24 23:22 PDT, Bruno 'Aqualon' Escherl
no flags Details
no crash testcase with position:relative (495 bytes, application/x-zip-compressed)
2004-05-24 23:25 PDT, Bruno 'Aqualon' Escherl
no flags Details
Minimal-ish testcase (370 bytes, text/html)
2004-05-25 11:35 PDT, Boris Zbarsky [:bz] (still a bit busy)
no flags Details
stack with some comments (4.39 KB, text/plain)
2004-06-06 21:56 PDT, David Baron :dbaron: ⌚️UTC-10
no flags Details
patch (10.35 KB, patch)
2004-06-07 13:03 PDT, David Baron :dbaron: ⌚️UTC-10
roc: review+
roc: superreview+
Details | Diff | Splinter Review

Description Johannes Walther 2004-05-23 14:01:55 PDT
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:  

Expected Results:  
Don't crash

MOZILLA verursachte einen Fehler durch eine ungültige Seite
in Modul <Unbekannt> bei 0000:0182968d.
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 
60294079 00000000 01837398 0182db10 0182d6a4 0064ef3c 602940fe 01d889b0 01d6f9e0
01d6f9f8 0064f040 018f5b84 00000000 017ed644 01837398 01837398 

Nothing on Linux, Mozilla just disappears.
Comment 1 Boris Zbarsky [:bz] (still a bit busy) 2004-05-23 14:25:39 PDT
I get the following assertions on load:

###!!! ASSERTION: Weird parent in ConstructTableForeignFrame: 'parentFrame ==
aState.mPseudoFrames.mCellInner.mFrame', file
line 2982
###!!! ASSERTION: RemovedAsPrimaryFrame called after PreDestroy: 'PR_FALSE',
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...
Comment 2 Stephen Donner [:stephend] 2004-05-23 16:18:44 PDT
Confirming crash with trunk build 2004-05-23-07 on Windows XP.

Full stacktrace coming as an attachment.

Comment 3 Stephen Donner [:stephend] 2004-05-23 16:19:09 PDT
Created attachment 149165 [details]
Comment 4 Bruno 'Aqualon' Escherl 2004-05-23 16:23:19 PDT
Created attachment 149166 [details]
Testcase for crash

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+
Comment 5 Martijn Wargers [:mwargers] (not working for Mozilla) 2004-05-23 16:31:50 PDT
Created attachment 149167 [details]
Another small crash testcase, a little smaller

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
Comment 6 Bernard Alleysson 2004-05-23 17:14:14 PDT
also crashes windows 1.7rc2 : TB57883G
Comment 7 Boris Zbarsky [:bz] (still a bit busy) 2004-05-23 20:00:20 PDT
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 Hermann Schwab 2004-05-23 23:26:05 PDT
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a2) Gecko/20040523

Talkback TB58111W on this minimized local copy:


<A><BLINK><FONT size=1><CENTER> 

<SCRIPT type=text/javascript>
document.write ("<script


<SCRIPT type=text/javascript>
document.write ("<script


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:
Comment 9 Boris Zbarsky [:bz] (still a bit busy) 2004-05-24 09:11:34 PDT
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 Hermann Schwab 2004-05-24 09:13:23 PDT
Created attachment 149213 [details]
700 byte zipped testcase, local

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 Hermann Schwab 2004-05-24 09:34:42 PDT
TB58726G crash with local testcase

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a2) Gecko/20040523

<A><BLINK><FONT size=1><CENTER> 
<SCRIPT type=text/javascript>document.write ("<script
<SCRIPT type=text/javascript>document.write ("<script

file 1f.js:

var ba = '';
ba += '<'+'div id="beacon_39" style="position: absolute; left: 0px; top: 0px;
visibility: hidden;"><'+'/div>';

file 2f.js:

var ba = '';
ba += '<'+'table border="2" color="black" width="130" cellspacing="1"
ba += '<'+'tr><'+'td width="143" align="center"><'+'/td>\n  <'+'/tr>\n
Comment 12 Hermann Schwab 2004-05-24 15:28:34 PDT

DoDeletingFrameSubtree 585be954

Access violation
line 9103

js files can even be more reduced:

var ba = '';
ba += '<'+'div style="position: absolute; left: 0px; top: 0px;"><'+'/div>';

var ba = '';
ba += '<'+'table width="130"><'+'tr><'+'td><'+'/td><'+'/tr><'+'/table>';
Comment 13 Boris Zbarsky [:bz] (still a bit busy) 2004-05-24 19:36:36 PDT
In fact, you could even get rid of the intermediary variables in the JS files

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 Bruno 'Aqualon' Escherl 2004-05-24 23:22:48 PDT
Created attachment 149251 [details]
crash testcase with position:absolute
Comment 15 Bruno 'Aqualon' Escherl 2004-05-24 23:25:50 PDT
Created attachment 149252 [details]
no crash testcase with position:relative

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 Bruno 'Aqualon' Escherl 2004-05-24 23:31:56 PDT
(In reply to comment #13)

document.write without a <script> and a extern .js file as src doesn't crash.

Comment 17 Boris Zbarsky [:bz] (still a bit busy) 2004-05-25 11:35:05 PDT
Created attachment 149288 [details]
Minimal-ish testcase

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.
Comment 18 chris hofmann 2004-05-27 07:06:32 PDT
bz, does it look like it might be a straight forward fix, or complicated?
Comment 19 Boris Zbarsky [:bz] (still a bit busy) 2004-05-27 11:30:20 PDT
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 Boris Zbarsky [:bz] (still a bit busy) 2004-05-27 11:34:35 PDT
Note that I tried to wallpaper over this by adding:


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.  :(
Comment 21 David Baron :dbaron: ⌚️UTC-10 2004-06-04 18:03:41 PDT
Marking blocking1.7+, although this is at risk for being minused, since we're
hoping to ship early next week.
Comment 22 David Baron :dbaron: ⌚️UTC-10 2004-06-06 21:56:42 PDT
Created attachment 150169 [details]
stack with some comments

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?
Comment 23 David Baron :dbaron: ⌚️UTC-10 2004-06-07 12:40:41 PDT
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
Comment 24 David Baron :dbaron: ⌚️UTC-10 2004-06-07 12:58:04 PDT
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.
Comment 25 David Baron :dbaron: ⌚️UTC-10 2004-06-07 13:03:20 PDT
Created attachment 150223 [details] [diff] [review]
Comment 26 David Baron :dbaron: ⌚️UTC-10 2004-06-17 11:51:38 PDT
Fix checked in to trunk, 2004-06-17 11:51 -0700.
Comment 27 Stephen Donner [:stephend] 2004-06-30 16:56:33 PDT
Verified FIXED with build 2004-06-30-08 on Windows XP.
Comment 28 timeless 2004-12-17 00:56:46 PST
*** Bug 271338 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.