Open Bug 500237 Opened 13 years ago Updated 7 years ago

Hang while loading the page [@ nsFrameList::InsertFrames]


(Core :: Layout, defect)

Not set



Tracking Status
status1.9.1 --- wanted


(Reporter: avl555, Unassigned)



(Keywords: perf, testcase)


(6 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; nl; rv: Gecko/2009060215 Firefox/3.0.11 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; nl; rv: Gecko/2009060215 Firefox/3.0.11 (.NET CLR 3.5.30729)

The main window says "not responding" while loading the page

I have tured off all add-ons and the problem is still there.
When I am quick and close the window, firefox alives.

When I close Firefox (at the hard way) and start Firefox, 

(Sorry, my English is not very well...)

Reproducible: Always

Steps to Reproduce:
1. It is always when I open that page.
2. When I restart firefox (at the hard way), Firefox crashes for the second time.
   I has time to close the tab, then Firefox doesn't crash.
Actual Results:  
Firefox crashes. It shows Not Responding.

Expected Results:  
Load the page normally.

I don't know in which module it crashes.
It still happened when I disable all add-ons.
This is my first bug report, sorry if there are bugs in this report...
This is a problem for me too. I reproduce this bug every day, including today.
The CPU usage goes up to 60% using 864MB memory. Not able to do anything else until Firefox app is killed.

Specs: Firefox 3.0.11, Windows Vista Home

1. Start Firefox, open multiple tabs (yahoo mail, google news, etc)
2. Go to Myspace page:
3. Hit play on Myspace music player (play list) or photo slide show
Note: the more songs you play, the worse the CPU usage gets

Result: Firefox hags taking up too much memory and CPU to do anything else
Example: Opening this bug after playing 3 songs on myspace in another tab took 2 minutes
Flags: blocking1.9.0.12?
This sounds like it could actually be a problem in flash (the myspace music player uses flash). I'm not seeing the same crash though.

Make sure you are using the latest flash player. Also, you might want to start at and work your way through the knowledge base, forums, and/or live chat - if it turns out to be a bug in firefox the volunteers there can help you gather the information we need for a useful bug report - we usually need enough that we can consistently make the issue happen on our own systems, so that we can find out what's wrong and get it fixed.

Closing this as incomplete (not enough information) for now, but should more information become available, we'll reopen this.
Closed: 13 years ago
Resolution: --- → INCOMPLETE
The reported hang from comment 0 is clearly reproducible with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5 ID:20090624012136. So why this bug is incomplete? Comment 3 has nothing to do with this bug report and should not be used to close this bug.

Bugs should be closed as incomplete after 2-3 weeks of inactivity means no report from the reporter. Otherwise we will loose such important reports.
Flags: wanted1.9.1.x?
Keywords: hang
OS: Windows XP → All
Hardware: x86 → All
Resolution: INCOMPLETE → ---
Version: unspecified → 3.0 Branch
Ever confirmed: true
(In reply to comment #3)
> This is a problem for me too. I reproduce this bug every day, including today.
> The CPU usage goes up to 60% using 864MB memory. Not able to do anything else
> until Firefox app is killed.

Oksana, can you please file it as a new bug and CC me? Thanks.

attach to your hung browser, according to the instructions and the use:

!analyze -v -hang

attach the resultant log.
It is in the works.. Will attach right now.
Component: General → Layout
Keywords: testcase-wanted
Product: Firefox → Core
QA Contact: general → layout
Summary: Crashed while loading the page. → Hang while loading the page
Version: 3.0 Branch → Trunk
seems to be under nsXMLHttpRequest::GetResponseText. my guess is that the page request has a *huge* amount of junk or something.

You can go to that frame, something like:

.frame 11
dt this nsXMLHttpRequest
dt this nsXMLHttpRequest mFoo
and try to find out what the url is or something.
Attached file 2nd hung analyses
Mmh, the analysis differs while running it a second time. That one also matches the stack I get under OS X with gdb now. Are we trying to insert Frames in an infinit loop? I'll also attach a shark profile.
Ok, the hang definitely happens in nsFrameList::InsertFrames. Setting a break onto nsXMLHttpRequest::GetResponseText only stops once.

Breakpoint 2, nsFrameList::InsertFrames (this=0x27a3f0dc, aParent=0x27a3f0a8, aPrevSibling=0x0, aFrameList=0x27a3f070) at /data/build/shiretoko/layout/generic/nsFrameList.cpp:205
205	  NS_PRECONDITION(nsnull != aFrameList, "null ptr");
(gdb) l
200	void
201	nsFrameList::InsertFrames(nsIFrame* aParent,
202	                          nsIFrame* aPrevSibling,
203	                          nsIFrame* aFrameList)
204	{
205	  NS_PRECONDITION(nsnull != aFrameList, "null ptr");
206	  if (nsnull != aFrameList) {
207	    nsIFrame* lastNewFrame = nsnull;
208	    if (aParent) {
209	      for (nsIFrame* frame = aFrameList; frame;

(gdb) p *aFrameList
$7 = (nsInlineFrame) {
  <nsHTMLContainerFrame> = {
    <nsContainerFrame> = {
      <nsSplittableFrame> = {
        <nsFrame> = {
          <nsBox> = {
            <nsIFrame> = {
              <nsISupports> = {
                _vptr$nsISupports = 0x131789a8
              members of nsIFrame: 
              mRect = {
                x = 0, 
                y = 0, 
                width = 0, 
                height = 0
              mContent = 0x1d2de5c0, 
              mStyleContext = 0x2607e4b4, 
              mParent = 0x27a3eff4, 
              mNextSibling = 0x262b03d8, 
              mState = 1026
            members of nsBox: 
            static gGotTheme = 1, 
            static gTheme = 0x15a797f0
          <nsIFrameDebug> = {
            <nsISupports> = {
              _vptr$nsISupports = 0x13178c18
            }, <No data fields>}, <No data fields>}, 
        members of nsSplittableFrame: 
        mPrevContinuation = 0x27a3efbc, 
        mNextContinuation = 0x0
      members of nsContainerFrame: 
      mFrames = {
        mFirstChild = 0x27a3f02c
    }, <No data fields>}, <No data fields>}

205	  NS_PRECONDITION(nsnull != aFrameList, "null ptr");
(gdb) p *aFrameList
$8 = (nsContinuingTextFrame) {
  <nsTextFrame> = {
    <nsFrame> = {
      <nsBox> = {
        <nsIFrame> = {
          <nsISupports> = {
            _vptr$nsISupports = 0x1317afa8
          members of nsIFrame: 
          mRect = {
            x = 0, 
            y = 0, 
            width = 0, 
            height = 0
          mContent = 0x1d2de7b0, 
          mStyleContext = 0x22898f7c, 
          mParent = 0x27a3f0a8, 
          mNextSibling = 0x0, 
          mState = 132098
        members of nsBox: 
        static gGotTheme = 1, 
        static gTheme = 0x15a797f0
      <nsIFrameDebug> = {
        <nsISupports> = {
          _vptr$nsISupports = 0x1317b200
        }, <No data fields>}, <No data fields>}, 
    members of nsTextFrame: 
    mNextContinuation = 0x0, 
    mContentOffset = 1, 
    mContentLengthHint = 0, 
    mAscent = 0, 
    mTextRun = 0x0
  members of nsContinuingTextFrame: 
  mPrevContinuation = 0x262b0508
Summary: Hang while loading the page → Hang while loading the page [@ nsFrameList::InsertFrames]
This won't block, but is it a regression? Can we get a regression range?
Flags: blocking1.9.0.12? → blocking1.9.0.13?
If it's a regression then it is a way old. Firefox also hangs while loading this page.
I tried 3.1b3 and it hangs. All of them eventually come back with "Warning: Unresponsive Script." And at least in the latest Shiretok/Minefield nightlies, when I continued, they eventually load the page.
Tried with same steps, added youtube page viewing, playing videos. Firefox crashed at once and close all tabs. Here is the crash report from Windows:

Add-ons: {CF40ACC5-E1BB-4aff-AC72-04C2F616BCA7}:,{20a82645-c095-46ed-80e3-08825760534b}:1.0,{635abd67-4fe9-1b23-4f01-e679fa7484c1}:,{972ce4c6-7e08-4474-a285-3208198ce6fd}:3.0.11
BuildID: 2009060215
CrashTime: 1246337773
InstallTime: 1245020224
ProductName: Firefox
SecondsSinceLastCrash: 3547064
StartupTime: 1246308534
Theme: classic/1.0
Vendor: Mozilla
Version: 3.0.11

This report also contains technical information about the state of the application when it crashed.
Oksana, as I have already said please file a new bug for your issue. It is not related to this problem. Thanks.
ok, this is now a new bug #501304
Flags: blocking1.9.0.13? → wanted1.9.0.x+
Whiteboard: [sg:dos]
FWIW, I loaded the query in comment 0 and it "hung" the browser for about a minute but eventually finished loading.
I can confirm comment of Brandon. The sites works correctly, but you have to wait for a minute.

Because of the complexity of the scripts, it is not so easy to find the real problem by reducing. I suggest, someone runs a profile on Firefox, to see were the cycles are going.

It is just a very bad performance of innerHTML.

innerHTML with data larger than 500kb start to become very slow.

This is probably a duplicate of bug 506844.

That bug claims also that use innerHTML can lead to crash if emptied afterwards. Can not reproduce that.

The other bug also claims that the problem is in FF3 but not in FF2.
This bug also exists in Firefox So I'm not sure if both bugs are related.
The problem is with the use of innerHTML and <span> construct.

The file in the attachment takes about 1 minute to load on my PC, while IE/Safari/Chrome load it within a second. There is clearly a quadratic algorithm here, where IE/Safari/Chrome are linear.

If you replace the <span> by <div> then the response is much faster. Although, in general the innerHTML performance is not good compared to the other browsers (with div it is about 2-3 times slower than IE).

I suggest that we continue this bug for slow innerHTML and use the other bug for innerHTML and setting it to '' and crashing it (which is an entire different problem).
Hmmm strange, when I load from the attachment it is significant faster than from file. How could that be?
Of course, the string could be generated with a script. This makes the file much smaller. IE has no problems with this. take almost two minutes to load for me with IE 8. takes less then 10 seconds to load in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090731 Minefield/3.6a1pre (.NET CLR 3.5.30729) ID:20090731091755

The 10 seconds for Firefox can be explained by much faster PC. I use a laptop.

I can't explain your long IE 8 load. For me it is less than 1 second. You are sure you use latest IE 8 version? And how about Safari? In Safari it also loads within a second.
Bug 506844 was talking about a problem with clearing the 'div'. If performance deteriorates due to span, then it also deteriorates in cleaning up.

So, I assume bug 506844 is not a crash, but a hang (and a dupe of this one).
Flags: wanted1.9.1.x?
dveditz, what is the status here?  You marked this as wanted-1.9.0.x but this definitely long missed this and missed 1.9.1 (so far at least) about 1.9.2?
Flags: wanted1.9.2?
Did this get better since bug 507023 was fixed?
No, still freeze the browser for about a minute.
Flags: wanted1.9.2? → wanted1.9.2+
Should this bug get a little bit more attention? It is perceived as a crash for the user and it is a performance issue. Both important for 3.6.
Just put it on the list for blocking1.9.2 so roc can decide...
Flags: blocking1.9.2?
Flags: blocking1.9.2? → blocking1.9.2-
I can reproduce the Issue on the attached Testcases against Firefox/3.5.19 ID:20110420144310, but not against 3.6 and upwards (incl. current Trunk) => WFM?
Can the reporter, or someone who was able to reproduce this before, try with 3.6, or a later supported release (eg. 5.0.1)?
The attached testcases both render in under 5 seconds for me.... is this bug still an issue?
The "Same test case with clear button." test is still very slow for me on trunk.
Rendering the page the first time something like 10s and pressing the "Clear" button will freeze Mozilla appr. 20s.
I see about 1.4s for the load.  The clear is indeed slow (10.5s or so), but that's bug 506844.
Depends on: 506844
Hrm, apparently, I overreacted. Loading is more like 2s (I thought it was 10s).
However, scrolling is very slow, too.
All Testcases are WFM now (including Loading/Scrolling/Clearing) against Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:13.0a1) Gecko/20120216 Firefox/13.0a1 ID:20120216031231 => WFM?
The performance doesn't look that bad to me.  It's still noticeably slower than Chrome
on the same machine when resizing the window though (on Linux64).
Severity: critical → normal
Keywords: hang
Whiteboard: [sg:dos]
You need to log in before you can comment on or make changes to this bug.