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)
Tracking
()
VERIFIED
FIXED
mozilla1.6alpha
People
(Reporter: jhansonxi, Assigned: bzbarsky)
References
()
Details
(Keywords: hang, qawanted)
Attachments
(4 files, 1 obsolete file)
122.83 KB,
application/octet-stream
|
Details | |
7.47 KB,
text/plain
|
Details | |
214.87 KB,
image/jpeg
|
Details | |
3.55 KB,
patch
|
dbaron
:
review+
dbaron
:
superreview+
dbaron
:
approval1.6a+
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•21 years ago
|
||
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".
Comment 2•21 years ago
|
||
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
Comment 3•21 years ago
|
||
Hmmm. Is there a cycle in the frame (not-a-?)tree or something?
Comment 5•21 years ago
|
||
It seem to work with the lastest build but the formatting seem to be off. Some of the words go out of the box.
Comment 7•21 years ago
|
||
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
Comment 8•21 years ago
|
||
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.
Comment 9•21 years ago
|
||
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).
Comment 10•21 years ago
|
||
Same behaviour observed here using Firebird 0.6.1: http://www.technewsworld.com/perl/story/31583.html
Comment 11•21 years ago
|
||
This link shows very similar behaviour: http://www.ecommercetimes.com/perl/story/31586.html on Firebird 0.6.1
Updated•21 years ago
|
QA Contact: ian → nobody
Comment 12•21 years ago
|
||
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.
Comment 13•21 years ago
|
||
same problem observed linux mozilla 1.2.1 - with the link http://www.technewsworld.com/perl/story/31632.html
Comment 14•21 years ago
|
||
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.
Comment 15•21 years ago
|
||
One more thing: Mozilla hangs on comment #13 link even with both JavaScript and Java switched off.
Comment 16•21 years ago
|
||
*** Bug 220153 has been marked as a duplicate of this bug. ***
Comment 17•21 years ago
|
||
Same behaviour observed here using Firebird 0.6 on Windows NT 4.0 SP6 http://technewsworld.com/perl/story/31643.html
Comment 18•21 years ago
|
||
*** Bug 218263 has been marked as a duplicate of this bug. ***
Comment 19•21 years ago
|
||
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))
Comment 20•21 years ago
|
||
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.
Assignee | ||
Comment 21•21 years ago
|
||
Any progress on isolating the script or HTML that does it? It's very hard to do anything here otherwise....
Comment 22•21 years ago
|
||
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.
Assignee | ||
Comment 23•21 years ago
|
||
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?
Comment 24•21 years ago
|
||
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.
Comment 25•21 years ago
|
||
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
Comment 26•21 years ago
|
||
*** Bug 219546 has been marked as a duplicate of this bug. ***
Comment 27•21 years ago
|
||
*** Bug 218684 has been marked as a duplicate of this bug. ***
Comment 28•21 years ago
|
||
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]
Comment 29•21 years ago
|
||
*** Bug 219830 has been marked as a duplicate of this bug. ***
Comment 30•21 years ago
|
||
*** Bug 220778 has been marked as a duplicate of this bug. ***
Comment 31•21 years ago
|
||
*** Bug 222872 has been marked as a duplicate of this bug. ***
Comment 32•21 years ago
|
||
*** Bug 223037 has been marked as a duplicate of this bug. ***
Comment 33•21 years ago
|
||
*** Bug 223441 has been marked as a duplicate of this bug. ***
Comment 34•21 years ago
|
||
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.
Comment 35•21 years ago
|
||
Alright. What's with Bugzilla not wrapping my posts when I post with Firebird? Is this another bug?
Comment 36•21 years ago
|
||
*** Bug 223765 has been marked as a duplicate of this bug. ***
Updated•21 years ago
|
Flags: blocking1.6a?
Assignee | ||
Comment 37•21 years ago
|
||
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....
Assignee | ||
Comment 38•21 years ago
|
||
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 :-) ).
Assignee | ||
Comment 41•21 years ago
|
||
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
Assignee | ||
Comment 42•21 years ago
|
||
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+
Assignee | ||
Comment 43•21 years ago
|
||
Naturally, we have code triggering that assert... ;) This should fix that.
Assignee | ||
Updated•21 years ago
|
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.
Assignee | ||
Comment 45•21 years ago
|
||
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...
Assignee | ||
Comment 47•21 years ago
|
||
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?
Assignee | ||
Comment 48•21 years ago
|
||
Checked in just the nsCSSFrameConstructor changes.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Updated•21 years ago
|
Flags: blocking1.6a?
Comment 49•21 years ago
|
||
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
Comment 50•21 years ago
|
||
wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6a) Gecko/20031028 tested all links here with a trunk build.
Comment 51•21 years ago
|
||
*** Bug 224319 has been marked as a duplicate of this bug. ***
Comment 52•21 years ago
|
||
*** Bug 224978 has been marked as a duplicate of this bug. ***
Comment 53•21 years ago
|
||
*** Bug 225477 has been marked as a duplicate of this bug. ***
Comment 54•21 years ago
|
||
*** Bug 226090 has been marked as a duplicate of this bug. ***
Comment 55•21 years ago
|
||
*** Bug 226354 has been marked as a duplicate of this bug. ***
Comment 56•21 years ago
|
||
*** Bug 226441 has been marked as a duplicate of this bug. ***
Comment 57•21 years ago
|
||
*** Bug 227000 has been marked as a duplicate of this bug. ***
Comment 58•21 years ago
|
||
*** Bug 226250 has been marked as a duplicate of this bug. ***
Comment 59•21 years ago
|
||
*** Bug 227775 has been marked as a duplicate of this bug. ***
Comment 60•21 years ago
|
||
*** Bug 229539 has been marked as a duplicate of this bug. ***
Comment 61•21 years ago
|
||
*** Bug 224102 has been marked as a duplicate of this bug. ***
Comment 62•20 years ago
|
||
*** Bug 232103 has been marked as a duplicate of this bug. ***
Comment 63•20 years ago
|
||
*** Bug 226840 has been marked as a duplicate of this bug. ***
Comment 64•20 years ago
|
||
*** 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.
Description
•