Closed Bug 218512 Opened 21 years ago Closed 21 years ago

[FIXr]browser freezes (SCO kills Mozilla through TechNewsWorld (hang)) [@ PositionChildViews]

Categories

(Core :: Layout, defect, P1)

x86
All
defect

Tracking

()

VERIFIED FIXED
mozilla1.6alpha

People

(Reporter: jhansonxi, Assigned: bzbarsky)

References

()

Details

(Keywords: hang, qawanted)

Attachments

(4 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624

Go to the article titled "SCO vs. IBM:  The Other Reality".
Page never finishes loading and CPU gets pegged at 99% by Mozilla.

Reproducible: Always

Steps to Reproduce:
1.  Go to http://www.technewsworld.com/perl/story/31479.html
2.  Wait
3.  Keep waiting
4.  Give up - Click the window close button and tell XP to kill it when it is
not responding.
Actual Results:  
Hang.  Some page text and boxes are displayed but nothing else.  Can't scroll.

Expected Results:  
Not hang

Date tested - September 6, 2003 - Ads may be the source.
Works in IE 6.
When loaded in Mozilla, an error message pops up:
"c is not a registered protocol"
But the page doesn't hang.  IE 6 had trouble saving the page.  Usual
descriptive IE error message:  "The page could not be saved".
confirming with win2k build 20030901..
Assignee: general → other
Severity: major → critical
Status: UNCONFIRMED → NEW
Component: Browser-General → Layout
Ever confirmed: true
Keywords: hang
QA Contact: general → ian
Hmmm.  Is there a cycle in the frame (not-a-?)tree or something?
It seem to work with the lastest build but the formatting seem to be off. Some
of the words go out of the box.
Any chance of a minimal-ish testcase?
Keywords: qawanted
I'm running an older version of Mozilla but I just wanted to chime in here, and
offer another URL at the same site which seems to hang my Mozilla by the neck.

http://www.technewsworld.com/perl/story/31303.html

Nothing SCOish on that page -- seems to be Technewsworld in general (I'm not
eager to test the rest of their site ...) although of course it's possible that
they are in a dark conspiracy with SCO :-)

I'm running lavaps and it showed this one Mozilla thread bobbing up and down
like crazy. top(1) showed mozilla-bin PID 15384 constantly on top, using >90%
CPU. System load went up to something like 1.5 (from like 0.1ish), then xload
went sharply up to about 4, then back down to around 1.5 and stayed there.
(Sorry, that part of my xload has scrolled off-screen already, but here is an
ASCII artist's recollection:
               ,
              #
             ##
     ##+##+#####+##+
.....###############

As you can see, the peak didn't occur immediately.) I tried to attach with gdb
but couldn't make much sense of what I was seeing, as I'm not familiar with
Mozilla's internals.

I couldn't see anything at all, I'm running half a dozen browser windows with
typically as many tabs as I can fit into one (crashing loses all this state
information, in spite of multizilla, grr) and none of the windows would even
update, much less respond in any way. I watched this for ten or fifteen minutes
before killing it off as an act of mercy. I then revisited the site with a new
Moz just to confirm; it died again.

I'm running Debian stable with a backport of Mozilla 1.3. My "about": says
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1; MultiZilla v1.1.23)
Gecko/20030524 Debian/1.3.1-1.he-1
Dumping the HTML to /tmp/31303.html and then visiting that works fine, and ads
are displayed intact so you can count those out. My guess would be something
with the style sheets.

I'm submitting a screen shot of this just for your entertainment.
Negative on the style sheets -- I downloaded /shared/tnwscreen.css, general.css,
and print.css into my /tmp and changed the HTML to get them from that location,
and I didn't get any crash. In fact, it now renders quite nicely (for an "angry
fruit salad" ad site). Ditto for the JavaScript in /shared/general.js ->
/tmp/general.js and all the images on the page (downloaded one at a time, reload
after each -- nothing! Furrfu).
Same behaviour observed here using Firebird 0.6.1:
http://www.technewsworld.com/perl/story/31583.html
This link shows very similar behaviour:
http://www.ecommercetimes.com/perl/story/31586.html
on Firebird 0.6.1
QA Contact: ian → nobody
Another site with a similar problem is linuxinsider.com, for example
http://www.linuxinsider.com/perl/story/31606.html
cannot be loaded in firebird or mozilla.
same problem observed linux mozilla 1.2.1 - with the link 
http://www.technewsworld.com/perl/story/31632.html
When a technewsworld link hanged my mozilla (1.5rc1 on WinME) today, its final
words in the status bar were: "Waiting for adfarm.mediaplex.com"

I hope that helps.
One more thing: Mozilla hangs on comment #13 link even with both JavaScript and
Java switched off.

*** Bug 220153 has been marked as a duplicate of this bug. ***
Same behaviour observed here using Firebird 0.6 on Windows NT 4.0 SP6
http://technewsworld.com/perl/story/31643.html
*** Bug 218263 has been marked as a duplicate of this bug. ***
Setting OS to ALL, as in duped Bug 218263

further candidates for duping:

Bug 216849  	firebird 0.6.1 hangs at 100% cpu on loading this particular
http://www.ecommercetimes.com/perl/story/31386.html

Bug 218684 Mozilla 1.4 freezes when this URL is accessed
http://www.ecommercetimes.com/perl/story/31516.html

Bug 219313 Mozilla sometimes freezes when ecommercetimes is visited
http://www.ecommercetimes.com/perl/story/31571.html  (duped to bug 218684)

Bug 219546 Mozilla1.5rc1: The browser hangs.
http://www.technewsworld.com/perl/story/31586.html

I tested in bug 219546 comment #8 different releases, got hangs depending on the
current ad (seen in another browser). Bug has stacktrace win2k debug.

Bug 219830 Freeze in gklayout.dll when loading or rendering this page
http://www.technewsworld.com/perl/story/31632.html

Bug 220778 browser stops responding during opening URL
http://www.linuxinsider.com/perl/story/31662.html
OS: Windows XP → All
Summary: SCO kills Mozilla through TechNewsWorld (hang) → browser freezes (SCO kills Mozilla through TechNewsWorld (hang))
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6a) Gecko/20030930
Shockwave Flash 7.0 r14, Java Plug-in 1.4.2_01 for Netscape Navigator

Tested all sites from my last comment, lots of flash, no Java.
3 of them hang instantly, the first and the fourth only after some Shift-Reloads.

So all of these sites hang, sometimes, maybe depending on the ad served.
All of them belong to ECT NEWS Network

From: http://www.ectnews.com/about/

The network currently includes several e-business and technology news sites: the
E-Commerce Times®, TechNewsWorldTM, LinuxInsiderTM and CRM Buyer MagazineTM.

Forbes Magazine has repeatedly recognized the E-Commerce Times as one of the top
10 technology news sites in its "Best of the Web" reviews.
Blocks: 220778
Any progress on isolating the script or HTML that does it?  It's very hard to do
anything here otherwise....
It is certainly not a script. Switching off Java and JavaScript does not help
(see my comment #15). 

It may be impossible to build a testcase as the hang happens with some ads and
does not happen with different ones. The fact that sometimes the hang happens
only after a Shift-Reload confirms this.
Doesn't have to be a "testcase", but even knowing the URL that hangs us could
help (if the server does random redirection for the ads, eg).  Perhaps running
with HTTP logging enabled until the browser hangs and attaching the log to this bug?
I spent about two hours trying to make a testcase. It seems the testcase will be
complicated as this is some complicated CSS problem. Most of the page layout is
needed plus possibly an ad of a certain size. To make it worse sometimes a few
Shift-Reloads are needed to create the hang.

My feeling: the more stripped the page is, the harder it is to trigger the hang,
but it is not very impotrant what exactly I strip as long as I leave the long
vertical ad image and a lot of the text above it, as well as most the <div
class="something"> tags as they control what CSS is used.
Checking in from bug 216849, a duplicate of this bug.

Upgraded to 0.7 milestone on win2k, started a new profile and turned off java
and javascript. Still hangs.

http://www.ecommercetimes.com/perl/story/31386.html

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 Firebird/0.7
No longer blocks: 219546
*** Bug 219546 has been marked as a duplicate of this bug. ***
No longer blocks: 218684
*** Bug 218684 has been marked as a duplicate of this bug. ***
The problem is a corrupt frame tree.
We get stuck in the loop in nsContainerFrame::PositionChildViews:

    while (childFrame) {
      // Position the frame's view (if it has one) and recursively
      // process its children
      PositionFrameView(aPresContext, childFrame);
      PositionChildViews(aPresContext, childFrame);

      // Get the next sibling child frame
      childFrame = childFrame->GetNextSibling();
    }

because |childFrame->GetNextSibling()| returns |childFrame|:

(gdb) p childFrame
$1 = (nsIFrame *) 0x8744068
(gdb) p *childFrame
$2 = {<nsISupports> = {_vptr. = 0x40b5a000}, mRect = {x = 3152, y = 20966, width
= 4992, height = 2144},
  mContent = 0x8737658, mStyleContext = 0x8743fc8, mParent = 0x871b4ac,
mNextSibling = 0x8744068, mState = 13631748}

nsFrame::ListTag says:
childFrame=Area(div)(32)@0x8744068
aFrame=Block(div)(9)@0x871b4ac
Summary: browser freezes (SCO kills Mozilla through TechNewsWorld (hang)) → browser freezes (SCO kills Mozilla through TechNewsWorld (hang)) [@ PositionChildViews]
*** Bug 219830 has been marked as a duplicate of this bug. ***
No longer blocks: 219830
*** Bug 220778 has been marked as a duplicate of this bug. ***
*** Bug 222872 has been marked as a duplicate of this bug. ***
*** Bug 223037 has been marked as a duplicate of this bug. ***
*** Bug 223441 has been marked as a duplicate of this bug. ***
How long is it going to take to fix this annoying bug.  Everytime I click on a link to an ecommercetimes.com or technewsworld.co article, Firebird dies.  Here are my description from Bug # 223441, which got marked as a duplicate of this:

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6a) Gecko/20031021 Firebird/0.7+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6a) Gecko/20031021 Firebird/0.7+


If you open any of the "TOP STORIES" links, at Ecommerce Times, in a tab - either by middle-clicing the mouse, CTRL + left mouse-clicking, or right-clicking and selecting "Open link in new tab", Firebird locks up solid (about 98 % of the time) and never recovers.  The only way to end the app' is through Task Manager.  If you don't end Firebird quick enough, after this lock-up happens, and try performing other operations in Windows, Windows eventuall becomes extremely sluggish and unresponsive, requiring a hard reboot.  Note: this lockup also occurs if you drag and drop the link onto the tab bar, to launch it in a new tab.  So far, I have experienced this bug only on ecommercetimes.com and technewsworld.com.

Reproducible: Always

Steps to Reproduce:
1. Visit http://www.ecommercetimes.com
2. Launch any of the story links (under "TOP STORIES" on the left) in a new tab.
3. Watch how she locks up after a few seconds of attempting to load the page!

Actual Results:  
Locks up the browser cold.

Expected Results:  
I should have rendered and displayed the page per normal browser behavior.

Bug experienced only on Ecommercetimes.com and Technewsworld.com.  Obviously, Firebird has problems rendering their content.

System:
Windows 2000 Server + SP4
Intel Celeron 700 MHz
512 MB RAM
MS Internet Explorer 6.0


Just discovered that simply clicking a link to an Ecommercetimes.com or Technewsworld.com article will also send Firebird packing.  For instance, if you are currently connected using Firebird builds 0.6+ to 0.7+, click here: http://www.technewsworld.com/perl/story/31932.html

and watch Firebird die.
Alright.  What's with Bugzilla not wrapping my posts when I post with Firebird?  Is this another bug?
*** Bug 223765 has been marked as a duplicate of this bug. ***
Flags: blocking1.6a?
Attached patch Possible patchSplinter Review
Mats, thanks for debugging!  This patch adds an assert to SetNextSibling() that
catches this case.  When I break at that assert, I'm at:

#1  0x4129e312 in nsIFrame::SetNextSibling(nsIFrame*) (this=0x8a9859c, 
    aNextSibling=0x8a9859c) at ../../../../dist/include/layout/nsIFrame.h:701
#2  0x41461a2a in nsFrameList::AppendFrames(nsIFrame*, nsIFrame*)
(this=0x89342cc, 
    aParent=0x0, aFrameList=0x8a9859c)
    at /home/bzbarsky/mozilla/debug/mozilla/layout/base/src/nsFrameList.cpp:144

#3  0x41297490 in nsBlockFrame::AppendFrames(nsIPresContext*, nsIPresShell&,
nsIAtom*, nsIFrame*) (this=0x8934288, aPresContext=0x88e0ea8,
aPresShell=@0x88cd518, 
    aListName=0x80d22f0, aFrameList=0x8a9859c)
    at
/home/bzbarsky/mozilla/debug/mozilla/layout/html/base/src/nsBlockFrame.cpp:4545

#4  0x413aea24 in nsCSSFrameConstructor::RecoverLetterFrames(nsIPresShell*,
nsIPresContext*, nsFrameConstructorState&, nsIFrame*) (this=0x88cd3e0,
aPresShell=0x88cd518, 
    aPresContext=0x88e0ea8, aState=@0xbfffcde0, aBlockFrame=0x8934288)
    at
/home/bzbarsky/mozilla/debug/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp:12718

#5  0x413a4115 in nsCSSFrameConstructor::ContentAppended(nsIPresContext*,
nsIContent*, int) (this=0x88cd3e0, aPresContext=0x88e0ea8,
aContainer=0x89cb5f0, aNewIndexInContainer=7)
    at
/home/bzbarsky/mozilla/debug/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp:8520


What this patch does is clear the frame constructor state's various special
lists after they've been inserted under their relevant containing blocks.  It
_looks_ like this should be safe to do, but I'm not quite sure....

Other possible fix would be to remove the "// Insert in floats too if needed"
part in RecoverLetterFrames (though this could break floated first-letters).

I've still not managed to construct a minimal testcase, but I'm failing to see
why this doesn't bite us all the time -- there is nothing clearing the state's
floater list between InsertOutOfFlowFrames() and RecoverLetterFrames(), so I'm
not sure why this doesn't break anytime a float containing block has a
first-letter style....
Comment on attachment 134212 [details] [diff] [review]
Possible patch

David?	Thoughts?  I really don't know this code well enough to judge whether
this is the right thing to do....
Attachment #134212 - Flags: superreview?(dbaron)
Attachment #134212 - Flags: review?(dbaron)
Comment on attachment 134212 [details] [diff] [review]
Possible patch

sure, this makes sense to me, although you might want to ask roc what he thinks
(since he wrote the function you're changing quite recently)
Attachment #134212 - Flags: superreview?(dbaron)
Attachment #134212 - Flags: superreview+
Attachment #134212 - Flags: review?(dbaron)
Attachment #134212 - Flags: review+
I have no reason to believe this is unsafe.

My reorg just consolidated the existing code, so it's really unrelated to your
fix (except without my reorg, you'd have had to fix this in four places :-) ).
Taking.
Assignee: other → bz-vacation
Priority: -- → P1
Summary: browser freezes (SCO kills Mozilla through TechNewsWorld (hang)) [@ PositionChildViews] → [FIXr]browser freezes (SCO kills Mozilla through TechNewsWorld (hang)) [@ PositionChildViews]
Target Milestone: --- → mozilla1.6alpha
Comment on attachment 134212 [details] [diff] [review]
Possible patch

I think it's worth trying this for 1.6a.  If there's code somewhere that
depends on the old behavior here, it would be good to flush it out...
Attachment #134212 - Flags: approval1.6a?
Attachment #134212 - Flags: approval1.6a? → approval1.6a+
Attached patch Need this too (obsolete) — Splinter Review
Naturally, we have code triggering that assert... ;)  This should fix that.
Attachment #134224 - Flags: superreview?(dbaron)
Attachment #134224 - Flags: review?(dbaron)
Attachment #134224 - Flags: approval1.6a?
Comment on attachment 134224 [details] [diff] [review]
Need this too

Maybe it's better to skip the assert?  It should be pretty obvious when we end
up with a circular frame tree.
Comment on attachment 134224 [details] [diff] [review]
Need this too

Either way, I guess... It took awhile in this bug; once the assert was there
finding the bad caller was easy.  I can go ahead and check in the non-assert
part of the patch for 1.6a and the rest later or not at all, as you prefer...
Either later or not-at-all, I think...
Comment on attachment 134224 [details] [diff] [review]
Need this too

OK.  not-at-all it is, then.  ;)
Attachment #134224 - Attachment is obsolete: true
Attachment #134224 - Flags: superreview?(dbaron)
Attachment #134224 - Flags: review?(dbaron)
Attachment #134224 - Flags: approval1.6a?
Checked in just the nsCSSFrameConstructor changes.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Flags: blocking1.6a?
No hang with a fresh CVS builds on Win32 and Linux (there are no fresh nightly
win32 builds since 1025).

I checked all the links from this bug: no problems. 

Verifying fixed... 
...and hoping that nobody@mozilla.org will not get angry for doing QA work for
him/her/it ;-)
Status: RESOLVED → VERIFIED
wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6a) Gecko/20031028
tested all links here with a trunk build.
*** Bug 224319 has been marked as a duplicate of this bug. ***
*** Bug 224978 has been marked as a duplicate of this bug. ***
*** Bug 225477 has been marked as a duplicate of this bug. ***
*** Bug 226090 has been marked as a duplicate of this bug. ***
*** Bug 226354 has been marked as a duplicate of this bug. ***
*** Bug 226441 has been marked as a duplicate of this bug. ***
*** Bug 227000 has been marked as a duplicate of this bug. ***
*** Bug 226250 has been marked as a duplicate of this bug. ***
*** Bug 227775 has been marked as a duplicate of this bug. ***
*** Bug 229539 has been marked as a duplicate of this bug. ***
*** Bug 224102 has been marked as a duplicate of this bug. ***
*** Bug 232103 has been marked as a duplicate of this bug. ***
*** Bug 226840 has been marked as a duplicate of this bug. ***
*** Bug 240000 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.