1003427 - All version of Firefox hangs on attached page

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Mikhail]

Attachment: syrena-kill.tar.gz

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 Firefox/32.0 (Beta/Release)
Build ID: 20140429030201

Steps to reproduce:

1. Extract all archive content
2. Open index.html


Actual results:

 Firefox hangs


Expected results:

 Firefox not consume all CPU resources and display attached page

Comment 1

[Mikhail]

Tested on Fedora 20 x64 and i686

Comment 2

[sjw]

I can confirm this on Ubuntu 14.04. But this might be a Core bug.

Comment 3

[:Gijs (he/him)]

This is most likely a core bug, and so I don't think fx-backlog is appropriate here.

Comment 4

[:Gijs (he/him)]

I wonder if this is related to bug 999446. It hangs on my mac as well, in any case.

  Thread 0x16eb7    DispatchQueue 1          priority    0-47   cpu time   1.557s
  1  arena_dalloc + 830 (jemalloc.c:3073 in libmozglue.dylib) [0x10000941e]
    1  <executing in user space>
  1  nsTextFrame::IsEmpty() + 1 (nsTextFrame.cpp:8373 in XUL) [0x1026a8231]
    1  <executing in user space>
  1  nsBlockFrame::ReflowInlineFrames(nsBlockReflowState&, nsLineList_iterator, bool*) + 673 (nsBlockFrame.cpp:3439 in XUL) [0x102631741]
    1  <executing in user space>
  1  mozilla::FramePropertyTable::Remove(nsIFrame*, mozilla::FramePropertyDescriptor const*, bool*) + 9 (FramePropertyTable.cpp:108 in XUL) [0x1025ac509]
    1  <executing in user space>
  1  nsRuleNode::GetStylePosition(nsStyleContext*, bool) + 8 (.nsStyleStructList.h:82 in XUL) [0x102556238]
    1  <executing in user space>
  1  nsIPresShell::FontSizeInflationEnabled() + 11 (nsPresShell.cpp:10309 in XUL) [0x102596d1b]
    1  <executing in user space>
  1  nsInlineFrame::IsSelfEmpty() + 402 (BaseMargin.h:45 in XUL) [0x1026794d2]
    1  <executing in user space>
  1  nsIFrame::FinishAndStoreOverflow(nsOverflowAreas&, nsSize, nsSize*) + 2934 (nsRect.h:124 in XUL) [0x1026571c6]
    1  <executing in user space>
  1  ??? [0x120560c78]
    1  nsLineLayout::TrimTrailingWhiteSpaceIn(nsLineLayout::PerSpanData*, int*) + 430 (nsLineLayout.cpp:2381 in XUL) [0x10261f18e]
      1  <executing in user space>
  1  mozilla::FramePropertyTable::Remove(nsIFrame*, mozilla::FramePropertyDescriptor const*, bool*) + 71 (FramePropertyTable.cpp:118 in XUL) [0x1025ac547]
    1  <executing in user space>
  1  nsBlockFrame::PlaceLine(nsBlockReflowState&, nsLineLayout&, nsLineList_iterator, nsFloatManager::SavedState*, nsRect&, int&, bool*) + 401 (nsBlockFrame.cpp:4112 in XUL) [0x102633761]
    1  <executing in user space>
  1  nsLineLayout::FreeSpan(nsLineLayout::PerSpanData*) + 36 (nsLineLayout.cpp:546 in XUL) [0x10261c514]
    1  <executing in user space>
  1  nsOverflowAreas::UnionWith(nsOverflowAreas const&) + 42 (nsRect.h:124 in XUL) [0x10265ba7a]
    1  <executing in user space>
  1  ??? (firefox + 18446744069414586000) [0x690]
    1  nsTextFrame::GetType() const + 7 (nsTextFrame.cpp:8367 in XUL) [0x1026a8227]
      1  <executing in user space>
  1  arena_dalloc + 77 (jemalloc.c:1691 in libmozglue.dylib) [0x10000912d]
    1  syscall_thread_switch + 10 (libsystem_kernel.dylib) [0x7fff97a88b16]
     *1  ??? (mach_kernel + 247104) [0xffffff800023c540]
  1  nsHTMLScrollFrame::GetContentInsertionFrame() + 10 (nsGfxScrollFrame.h:517 in XUL) [0x10267d09a]
    1  <executing in user space>
  1  nsTextFrame::ReflowText(nsLineLayout&, int, nsRenderingContext*, nsHTMLReflowMetrics&, unsigned int&) + 4775 (nsCoord.h:254 in XUL) [0x1026a6d77]
    1  <executing in user space>

Comment 5

[:Gijs (he/him)]

Hrm, the stack seems to be different at different times, though - it's just being ridiculously slow about something:

  1 nsFont::BaseEquals(nsFont const&) const + 181 (nsTArray.h:368 in XUL) [0x10168f735]
    1 <executing in user space>
  1 PL_ArenaAllocate + 232 (libnss3.dylib) [0x10051e918]
    1 malloc + 42 (libsystem_malloc.dylib) [0x7fff8cb6e27c]
      1 arena_malloc + 1 (jemalloc.c:4142 in libmozglue.dylib) [0x10000e631]
        1 <executing in user space>
  1 nsBlockFrame::ReflowPushedFloats(nsBlockReflowState&, nsOverflowAreas&, unsigned int&) + 30 (nsFrameList.h:225 in XUL) [0x10262d70e]
    1 <executing in user space>
  1 nsLineLayout::NewPerFrameData(nsIFrame*) + 175 (nsStyleStructList.h:58 in XUL) [0x10261c95f]
    1 <executing in user space>
  1 ??? [0x7f0000000690]
    1 nsLineLayout::ReflowFrame(nsIFrame*, unsigned int&, nsHTMLReflowMetrics*, bool&) + 3166 (nsStyleStructList.h:58 in XUL) [0x10261d6fe]
      1 <executing in user space>
  1 nsFloatManager::GetFlowArea(int, nsFloatManager::BandInfoType, int, nsRect, nsFloatManager::SavedState*) const + 1 (nsFloatManager.cpp:116 in XUL) [0x102648ed1]
    1 <executing in user space>
  1 ??? [0x1091bdf80]
    1 ??? [0x10caa9800]
      1 nsHTMLScrollFrame::ReflowScrolledFrame(ScrollReflowState*, bool, bool, nsHTMLReflowMetrics*, bool) + 490 (nsHTMLReflowState.h:112 in XUL) [0x102663c3a]
        1 <executing in user space>
  1 nsRuleNode::GetStyleTextReset(nsStyleContext*, bool) + 8 (.nsStyleStructList.h:88 in XUL) [0x102556268]
    1 <executing in user space>
  1 PR_Lock + 1 (libnss3.dylib) [0x100519491]
    1 <executing in user space>
  1 pthread_setspecific + 99 (libsystem_pthread.dylib) [0x7fff8b88b4ef]
    1 <executing in user space>

Comment 6

[:Gijs (he/him)]

I'm not really getting anywhere with trying to profile or debug this (the profiler seems to not like stopping when the debuggee is hung), or even trying to simplify the testcase. Ms2ger, can you help out here in figuring out what's causing the hang, or suggest someone who can?

Also, Mikhail, do you know if this page worked fine on earlier versions of Firefox?

Comment 7

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

My first guess was a hit:

<bz> ms2ger: it's on my to-look-at list....
<bz> ms2ger: Assuming I can reproduce

Comment 8

[Simon Montagu :smontagu]

(In reply to :Gijs Kruitbosch from comment #4)
> I wonder if this is related to bug 999446.

Apparently not: I can reproduce the hang on older builds before the checkin that caused bug 999446, and also on a w-i-p patched build that doesn't hang with bug 999446's testcase

Comment 9

[:Gijs (he/him)]

This is still reproducible on current Nightly. bz, could you have a look, please? :-)

Comment 10

[Boris Zbarsky [:bzbarsky]]

Sadly, the profiler I normally use gives up the ghost on the 1000-deep stack traces I see in layout on this testcase.  :(

The relevant bits seem to be ionicons.css (well, the minified version, but I switched the testcase back to using the unminified one for simplicity), and in particular the combination of two things in there:

1)  The rule that sets all sorts of stuff to inline-block display.
2)  The lots of rules that add ::before content to various things.

and the fact that the HTML has tons of unclosed <i> tags like so:

                <a href="index.html">
                  <i class="nav-item-icon icon ion-social-rss-outline" />
                  Dashboard
                </a>
...
                <a href="#layouts">
                  <i class="nav-item-caret" />
                  <i class="nav-item-icon icon ion-ios7-monitor-outline" />
                  Layouts
                </a>

etc. which are all styled with those rules.

This leads to an explosion in the number of <i> nodes in the DOM, because of parser fixups; in particular there are about 1000 <i> nodes, most of them nested 100+-deep.

I'm not sure exactly where this is triggering O(N^2) behavior, but it clearly is.

I did check that it's not shrink-wraping that's being an issue: giving all the inline-blocks a fixed width doesn't help.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Attachment: Standalone testcase showing the problem

Comment 12

[Mikhail]

(In reply to :Gijs Kruitbosch from comment #9)
> This is still reproducible on current Nightly. bz, could you have a look,
> please? :-)

Yes, still reproducible on 35.0a1 (2014-09-29)

Comment 13

[Alice0775 White]

I can reproduce the hang with reduced testcase and testcase2 on Firefox55.
However, I can no longer reproduce the hang on Firefox56 x64 and later on Win10.

Fixed range:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=e6e712904806da25a9c8f48ea4533abe7c6ea8f4&tochange=d6bf703c5deaf1e328babd03d5e68ff2a4ffe10e

Fixed by: 
	1e3130e96f03	L. David Baron — Bug 1308876 - Mark child frames as dirty before starting reflow of the parent, so that if we reflow a child twice, it's only dirty the first time. r=dholbert