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

Status: RESOLVED INCOMPLETE

(Core :: Layout, defect)

Description

[avl555]

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

The main window says "not responding" while loading the page
http://www.google.nl/codesearch/p?hl=nl&sa=N&cd=2&ct=rc#hJEEg5iHYOI/tawiki/20071012/tawiki-20071012-langlinks.sql.gz&q=%22gmail%20drive%22&l=28

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.

Comment 1

[avl555]

This is my first bug report, sorry if there are bugs in this report...

Comment 2

[Tyler Downer [He/Him]]

Can you give a stacktrace (https://developer.mozilla.org/En/How_to_get_a_stacktrace_for_a_bug_report), and try reproducing in a new profile. http://support.mozilla.com/kb/Profiles

Comment 3

[Oksana]

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

Steps:
1. Start Firefox, open multiple tabs (yahoo mail, google news, etc)
2. Go to Myspace page: myspace.com/ksenia_vesennaya
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

Comment 4

[Stephanie Daugherty [:sdaugherty]]

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 http://support.mozilla.com 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.

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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.

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(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.

Comment 7

[timeless]

https://developer.mozilla.org/en/How_to_get_a_stacktrace_with_WinDbg

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

!analyze -v -hang

attach the resultant log.

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+2]]

It is in the works.. Will attach right now.

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Attachment: Hang analysis of WinDBG

Comment 10

[timeless]

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
dv
dt this nsXMLHttpRequest
dt this nsXMLHttpRequest mFoo
...
and try to find out what the url is or something.

Comment 11

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Attachment: 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.

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Attachment: Shark profile

Comment 13

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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
}

Comment 14

[Samuel Sidler (old account; do not CC)]

This won't block 1.9.0.12, but is it a regression? Can we get a regression range?

Comment 15

[Henrik Skupin [:whimboo][⌚️UTC+2]]

If it's a regression then it is a way old. Firefox 2.0.0.20 also hangs while loading this page.

Comment 16

[juan becerra [:juanb]]

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.

Comment 17

[Oksana]

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}:1.5.2.35,{20a82645-c095-46ed-80e3-08825760534b}:1.0,{635abd67-4fe9-1b23-4f01-e679fa7484c1}:1.5.1.20080205,{972ce4c6-7e08-4474-a285-3208198ce6fd}:3.0.11
BuildID: 2009060215
CrashTime: 1246337773
InstallTime: 1245020224
ProductName: Firefox
SecondsSinceLastCrash: 3547064
StartupTime: 1246308534
Theme: classic/1.0
URL: http://www.youtube.com/profile?migrated=1#play/all/uploads-all/1/wE-DhfOnaxs
Vendor: Mozilla
Version: 3.0.11

This report also contains technical information about the state of the application when it crashed.

Comment 18

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Oksana, as I have already said please file a new bug for your issue. It is not related to this problem. Thanks.

Comment 19

[Oksana]

ok, this is now a new bug #501304

Comment 20

[Brandon Sterne (:bsterne)]

FWIW, I loaded the query in comment 0 and it "hung" the browser for about a minute but eventually finished loading.

Comment 21

[u348128]

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.

Lucas

Comment 22

[u348128]

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.

Comment 23

[Henrik Skupin [:whimboo][⌚️UTC+2]]

This bug also exists in Firefox 2.0.0.20. So I'm not sure if both bugs are related.

Comment 24

[u348128]

Attachment: 60 times slower than IE/Chrome/Safari

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).

Comment 25

[u348128]

Hmmm strange, when I load from the attachment it is significant faster than from file. How could that be?

Comment 26

[u348128]

Attachment: Similar, but string now constructed. File very small.

Of course, the string could be generated with a script. This makes the file much smaller. IE has no problems with this.

Comment 27

[Bryan]

https://bugzilla.mozilla.org/attachment.cgi?id=391972 take almost two minutes to load for me with IE 8.

https://bugzilla.mozilla.org/attachment.cgi?id=391972 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

~B

Comment 28

[u348128]

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.

Comment 29

[u348128]

Attachment: Same test case with clear button.

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).

Comment 30

[u88484]

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)...how about 1.9.2?

Comment 31

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Did this get better since bug 507023 was fixed?

Comment 32

[Henrik Skupin [:whimboo][⌚️UTC+2]]

No, still freeze the browser for about a minute.

Comment 33

[u348128]

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.

Comment 34

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Just put it on the list for blocking1.9.2 so roc can decide...

Comment 35

[(mostly gone) XtC4UaLL [:xtc4uall]]

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?

Comment 36

[Tyler Downer [He/Him]]

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)?

Comment 37

[Boris Zbarsky [:bzbarsky]]

The attached testcases both render in under 5 seconds for me.... is this bug still an issue?

Comment 38

[Martijn Wargers (dead)]

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.

Comment 39

[Boris Zbarsky [:bzbarsky]]

I see about 1.4s for the load.  The clear is indeed slow (10.5s or so), but that's bug 506844.

Comment 40

[Martijn Wargers (dead)]

Hrm, apparently, I overreacted. Loading is more like 2s (I thought it was 10s).
However, scrolling is very slow, too.

Comment 41

[(mostly gone) XtC4UaLL [:xtc4uall]]

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?

Comment 42

[Mats Palmgren (inactive)]

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).

Comment 43

[Gregory Pappas [:gregp]]

URL 404s now and no archive can be located; closing.