271338 - crash when opening the page [@ DoDeletingFrameSubtree]

Status: RESOLVED DUPLICATE of bug 244454

(Core :: Layout, defect)

Description

[ayk]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

crash every time when opening the web page mentionned above.

Reproducible: Always
Steps to Reproduce:
1. open the url http://www.ac-nantes.fr/peda/disc/math/IPR/Documents/TerminS.htm
Actual Results:  
crash

Expected Results:  
showing the web page

Comment 1

[Adam Hauner]

Ayk: Could you please provide Talkback incident ID of your crash?

Comment 2

[Nagappan]

I'm able to reproduce the crash.

Comment 3

[ayk]

Adam Hauner : my Talkback incident ID is TB2126672G

Comment 4

[Hermann Schwab]

wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a5) Gecko/20041120

crash with Firefox 1.0: TB2142154E

Comment 5

[Hermann Schwab]

comment 3 TB2126672G:
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=2126672G

Stack Signature	 0x09b73281 15f24f25

DoDeletingFrameSubtree() 
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp,
line 683]

repeats forever, no other line found, so seems to be an endless loop.
Seen on Win98 too (TB2142154E) so confirming to all.
(The code must be somewhere else in Firefox/Win, but it is crashing.)

Comment 6

[Hermann Schwab]

http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB2142154E

endless repeating
DoDeletingFrameSubtree 
[c:/builds/tinderbox/firefox-aviarybranch-l10n/WINNT_5.1_Clobber/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp,
line 9161]
 9161 roc+      1.859      childFrame = childFrame->GetNextSibling();

http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp&mark=9161&rev=AVIARY_1_0_20040515_BRANCH#9161

searching for related bugs I found Bug 244454, TB2159125E, Bug 256108,
TB2159357Z long fixed on Trunk, but crashing in Firefox 1.0
couldn´t test Bug 256242, as it is not my mail hosting service.

Comment 7

[Boris Zbarsky [:bzbarsky]]

I just tested trunk builds back to when 1.7 branched, and none of them crash...

Given that this was confirmed without a minimal testcase, assigning to confirmer
to create said testcase.

Comment 8

[Hermann Schwab]

not much hance for a minimal testcase. I loaded the files I´d saved when I
confirmed into todays Mozilla and todays (1.8) Firefox nightly, no crash.

Same file loaded in Firefox 1.0 crashed immediately.
Disallowed JS, loading of images, outcommented style, crash.

The documents structure is simple, and I assume simply wrong.
Original size was 277 kb, I could reduce to about 200 kb.

There are a lot of <span ....> tags distributed in the code, summing up to
hundreds, and after a div or preceding the </body> about 200 </span> in one line.

The pattern is 

...
<div> some content </div>
<p><span...><span...><span...> some content </span></span></span></p>
<span...>
<span...>
<span...>
<span...>
<p><span...><span...><span...> some content </span></span></span></p>
<span...>
<span...>
<span...>
<span...>

If wanted, I can upload 200 kb.
Firefox trunk, based on Mozilla 1.8, didn´t crash.
Next I´ll check a current nightly of Mozilla 1.7.x as this will be the next
release, I assume.

http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB2358770H
TB2360862K, TB2360362M, TB2360309Q, TB2360223Y, TB2358770H

Loading the original URL, Firefox 1.0 was hanging, or crashing.
I don´t have extensions installed.

Comment 9

[Boris Zbarsky [:bzbarsky]]

> I could reduce to about 200 kb.

So at that point removing any tag would stop crashing?

Comment 10

[Hermann Schwab]

Retrying another way:
there are 2214 <span ... > tags and the same amount of </span>,
however there are relatively short sequences of <span> tags, the sequence
followed by <p> or <div>, but some long sequences of more than 200 </span> tags.

On the original file saved as HTML only I globally replaced <span with <SPPAN
and </span with </SPPAN, after this the page was loading fast and not crashing.
Cutting content before second div and content after second div reduced the size
from 212 to 166 kb  (the HTML size mentioned before of 283 kb was from save
complete, as the paths are longer).
I then removed the div tags, the file still was crashing.
It has 1415 <span> tags, 1415 </span> tags, 655 thereof just in one line with
and preceding the </div> tag. 

Does it make sense to reduce this further? I guess the problem is related to my
computer not having enough RAM (96 MB), and the crappy MSO styled HTML.
It depends on the amount of code.
When I commented out a part of the file, it was working, when I reversed this,
commenting out the other part, it was working too.
As the spans are nested, it is impossible for me to cut an amount of code
containing equal amount of <span> and </span>.
The 339 <p></p> seem to contain balanced spans, the imbalance is from the <span>
 inbetween. There are about 100 balanced <sub> and 9 balanced <sup>,
does it make sense to invalidate these?

I´ll retest at work on a 512 MB computer running Win98SE.

crashing:
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.5) Gecko/20041204
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a) Gecko/20040418 Firefox/0.8.0+


The original URL isn´t working today.
I´ve saved it at time of confirmation as both Webpage complete and HTML only.
Current testcase is 166 kB, working on trunk-based Mozilla and Firefox nightly,
crashing on Mozilla 1.7 nightly, and Firefox 1.0.

File sizes:
saved as HTML only: 212 kb
saved complete: 283 kb + 73 images, images zipped = 83kb
testcase: 166 kb, made from HTML only, no changes, only content outside one div
removed.

Comment 11

[Hermann Schwab]

regressed between 20040609 and 20040621

removing a span with position:absolute from the original file seems to fix the bug:

  <table border=0 cellspacing=0 cellpadding=0 style='border-collapse:collapse;
 '>
    <tr> 
      <td width=614 valign=top class="Normal" style='width:460.6pt;padding:0cm
3.5pt 0cm 3.5pt'> 
        <p class=MsoBodyText2> <span style=' 
position:absolute;z-index:0;margin-left:117px;margin-top:55px;width:413px;
  height:97px'> <img width=413 height=97 src="./terminS_fichiers/image049.gif"
  v:shapes="_x0000_s1045 _x0000_s1044 _x0000_s1029 _x0000_s1030 _x0000_s1032
_x0000_s1033 _x0000_s1034 _x0000_s1035 _x0000_s1036 _x0000_s1038 _x0000_s1039
_x0000_s1040"> 
                                        <img width=310 height=213
  src="./terminS_fichiers/image051.jpg" v:shapes="_x0000_i1054">  <i></i><span
  style='font-size:10.0pt;font-weight:normal'> 
          <p></p>
          </span></span></td>
    </tr>
  </table>

I removed:
<span style=' 
position:absolute;z-index:0;margin-left:117px;margin-top:55px;width:413px;
  height:97px'>

and a </span>, but didn´t remove the unbalanced <p>.

www.ac-nantes.fr can´t be reached, shall I upload the original files, zipped, or
as HTML?
The page, saved as HTML only, is 212 kb unzipped, and 28 kb zipped, and is
sufficient to show the bug. No JS included or needed, works with loading of
remote images allowed or denied.

Comment 12

[Boris Zbarsky [:bzbarsky]]

> regressed between 20040609 and 20040621

So this is a branch-only regression?

Comment 13

[Hermann Schwab]

(In reply to comment #12)
> > regressed between 20040609 and 20040621
> 
> So this is a branch-only regression?

Sorry, wrong wording, it isn´t a regression.
It is seen in the 1.7 Branch, and was seen in the early 1.8 trunk,
it was fixed in the trunk somewhere between 20040609 and 20040621.

I suppose it was fixed in trunk 2004-06-17 11:51 -0700 Bug 244454

Comment 14

[Boris Zbarsky [:bzbarsky]]

Yes, that would be likely....  In that case, please mark this duplicate.

Comment 15

[timeless]

*** Bug 269801 has been marked as a duplicate of this bug. ***

Comment 16

[timeless]

*** This bug has been marked as a duplicate of 244454 ***