Bug 1378601

Summary: Firefox consumes all available RAM and swap attempting to render a page on Bodhi
Product: [Fedora] Fedora Reporter: David H. Gutteridge <dhgutteridge>
Component: firefoxAssignee: Gecko Maintainer <gecko-bugs-nobody>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 24CC: fedora, gecko-bugs-nobody, jhorak, pjasicek
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-08-08 17:35:09 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Backtrace from gdb attached to firefox following instructions from fedora wiki page
none
valgrind log (see comment #3 for details) none

Description David H. Gutteridge 2016-09-22 21:08:50 UTC 
Description of problem:
When attempting to render https://bodhi.fedoraproject.org/updates/FEDORA-2016-77ffa78abb Firefox consumes all available RAM and swap, making my system almost completely unresponsive. I've tested both Firefox 48 and 49, and the problem is the same for both. (Though in 48, it also randomly starts overlaying bits of Firefox's graphical buffer onto other applications that have focus. I don't see that in 49.)

Version-Release number of selected component (if applicable):
firefox-49.0-2.fc24

How reproducible:
Always

Steps to Reproduce:
1. Load the page reference above.
2. Watch Firefox consume all RAM and start thrashing swap.

Actual results:
System becomes unresponsive.

Expected results:
Firefox should handle it more gracefully. In comparison, Epiphany also struggles to render that page, and never completes. It continuously consumes 100% of (one available) CPU as well, but never exhausts my system's memory. The whole desktop session remains responsive when Epiphany is trying to render the page.

(It seems there might be an issue at Bodhi's end as well, which would be a separate bug, of course. I haven't looked into the content of the page in question.)
Comment 1 Christian Stadelmann 2016-09-22 21:47:59 UTC 
You probably should debug this issue following these instructions: https://fedoraproject.org/wiki/Debugging_guidelines_for_Mozilla_products

I can reproduce this bug with tor browser too, which is an old (ESR) Firefox with Gtk2.

I can also reproduce this with Epiphany, so I reported a bug against WebKitGtk: https://bugs.webkit.org/show_bug.cgi?id=162465
Comment 2 Christian Stadelmann 2016-09-22 22:18:41 UTC 
Created attachment 1203925 [details]
Backtrace from gdb attached to firefox following instructions from fedora wiki page

Ok, I've decided to get the backtrace myself. Just couldn't wait ;)

This issue might be caused by the _very_ long website title of 3609 characters (!).

Some interesting observations on Firefox:
1. even though Firefox is running e10s (multi-process aka electrolysis), the bug is happening in the main process, not its WebContent process. This could be happening because by default the first tab is not enforced to be in a second process.
2. the status bar (or whatever it is called) is blinking, with at least two alternating labels: "Waiting for taskotron.fedoraproject.org…" and "Transferring data from taskotron.fedoraproject.org…"
3. firefox is very laggy but still reacts to user input. It even shuts down correctly if you close the window.

Affected versions:
firefox-49.0-2.fc24.x86_64 and older, including 45 ESR line shipped with tor browser

Steps to reproduce:
1. open Firefox
2. open this URL in firefox: https://bodhi.fedoraproject.org/updates/FEDORA-2016-77ffa78abb
3. watch RAM and CPU usage or wait for some time until the OOM killer starts eating processes

Expected behavior:
Moderate CPU and RAM usage, RAM usage should not increase over time

What happens:
RAM usage is increasing, about 1GB per minute

Additional info:
No plugins are running, no addons except system addons, this is reproducible on a fresh ("vanilla") profile.

Truncated backtrace:
#0  0x00007ffff6e463ed in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007fffe93b5850 in PollWrapper(GPollFD*, guint, gint) (ufds=ufds@entry=0x7fffcf726880, nfsd=nfsd@entry=5, timeout_=timeout_@entry=-1)
    at /usr/src/debug/firefox-49.0/firefox-49.0/widget/gtk/nsAppShell.cpp:42
#2  0x00007ffff3175a06 in g_main_context_iterate (priority=<optimized out>, n_fds=5, fds=0x7fffcf726880, timeout=<optimized out>, context=0x7ffff6ba4df0) at gmain.c:4135
#3  0x00007ffff3175a06 in g_main_context_iterate (context=context@entry=0x7ffff6ba4df0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3835
#4  0x00007ffff3175b1c in g_main_context_iteration (context=0x7ffff6ba4df0, 
    context@entry=0x0, may_block=1) at gmain.c:3901
#5  0x00007fffe93b58bf in nsAppShell::ProcessNextNativeEvent(bool) (this=<optimized out>, mayWait=<optimized out>) at /usr/src/debug/firefox-49.0/firefox-49.0/widget/gtk/nsAppShell.cpp:270
#6  0x00007fffe939d3e1 in nsBaseAppShell::DoProcessNextNativeEvent(bool) (this=this@entry=0x7fffd841c0e0, mayWait=<optimized out>) at /usr/src/debug/firefox-49.0/firefox-49.0/widget/nsBaseAppShell.cpp:138
#7  0x00007fffe939d5cc in nsBaseAppShell::OnProcessNextEvent(nsIThreadInternal*, bool) (this=0x7fffd841c0e0, thr=0x7fffe0c23280, mayWait=<optimized out>)
    at /usr/src/debug/firefox-49.0/firefox-49.0/widget/nsBaseAppShell.cpp:289
#8  0x00007fffe809026f in nsThread::ProcessNextEvent(bool, bool*) (this=0x7fffe0c23280, aMayWait=<optimized out>, aResult=0x7fffffffc237)
    at /usr/src/debug/firefox-49.0/firefox-49.0/xpcom/threads/nsThread.cpp:1038
#9  0x00007fffe80aad79 in NS_ProcessNextEvent(nsIThread*, bool) (aThread=<optimized out>, aMayWait=<optimized out>) at /usr/src/debug/firefox-49.0/firefox-49.0/xpcom/glue/nsThreadUtils.cpp:290
#10 0x00007fffe82bacc6 in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) (this=0x7fffe1ce0940, aDelegate=0x7ffff6b98780) at /usr/src/debug/firefox-49.0/firefox-49.0/ipc/glue/MessagePump.cpp:132
#11 0x00007fffe82a485a in MessageLoop::Run() (this=<optimized out>)
    at /usr/src/debug/firefox-49.0/firefox-49.0/ipc/chromium/src/base/message_loop.cc:228
#12 0x00007fffe82a485a in MessageLoop::Run() (this=<optimized out>)
    at /usr/src/debug/firefox-49.0/firefox-49.0/ipc/chromium/src/base/message_loop.cc:208
#13 0x00007fffe939bae6 in nsBaseAppShell::Run() (this=0x7fffd841c0e0)
    at /usr/src/debug/firefox-49.0/firefox-49.0/widget/nsBaseAppShell.cpp:156
#14 0x00007fffe99dfb6e in nsAppStartup::Run() (this=0x7fffd8402e70)
    at /usr/src/debug/firefox-49.0/firefox-49.0/toolkit/components/startup/nsAppStartup.cpp:284
#15 0x00007fffe9a18708 in XREMain::XRE_mainRun() (this=this@entry=0x7fffffffc4c8)
    at /usr/src/debug/firefox-49.0/firefox-49.0/toolkit/xre/nsAppRunner.cpp:4372
#16 0x00007fffe9a189ca in XREMain::XRE_main(int, char**, nsXREAppData const*) (this=this@entry=0x7fffffffc4c8, argc=argc@entry=3, argv=argv@entry=0x7fffffffd9e8, aAppData=aAppData@entry=0x7fffffffc6c8)
    at /usr/src/debug/firefox-49.0/firefox-49.0/toolkit/xre/nsAppRunner.cpp:4476
#17 0x00007fffe9a18c10 in XRE_main(int, char**, nsXREAppData const*, uint32_t) (argc=3, argv=0x7fffffffd9e8, aAppData=0x7fffffffc6c8, aFlags=<optimized out>)
    at /usr/src/debug/firefox-49.0/firefox-49.0/toolkit/xre/nsAppRunner.cpp:4584
#18 0x0000555555559249 in do_main(int, char**, char**, nsIFile*) (argc=3, argv=0x7fffffffd9e8, envp=<optimized out>, xreDirectory=0x7ffff6ba59c0)
    at /usr/src/debug/firefox-49.0/firefox-49.0/browser/app/nsBrowserApp.cpp:242
#19 0x00005555555587ff in main(int, char**, char**) (argc=3, argv=0x7fffffffd9e8, envp=0x7fffffffda08)
    at /usr/src/debug/firefox-49.0/firefox-49.0/browser/app/nsBrowserApp.cpp:383
Comment 3 Christian Stadelmann 2016-09-22 22:56:15 UTC 
Created attachment 1203926 [details]
valgrind log (see comment #3 for details)

For the graphical artefacts: I don't see any on F49, but once it seemed like the page was cut off after scrolling ca. 1.5 screen heights down.

Attaching valgrind to FF was quite tricky with --leak-check=full but it finally worked. See attached file.
Comment 4 Christian Stadelmann 2016-09-24 22:09:53 UTC 
Bodhi issue: https://github.com/fedora-infra/bodhi/issues/957

WebKit people decided to close the bug because *the website is broken and we don't want to fix it*
Comment 5 Fedora End Of Life 2017-07-25 23:11:45 UTC 
This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '24'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Comment 6 David H. Gutteridge 2017-07-26 00:17:28 UTC 
I can't reproduce this with Firefox 54 on Fedora 25; however, Bodhi has been changed in the interim to behave better in this regard, so its current representation of the original sample URL is no longer a viable test.
Comment 7 Christian Stadelmann 2017-07-26 20:13:55 UTC 
(In reply to David H. Gutteridge from comment #6)
> I can't reproduce this with Firefox 54 on Fedora 25; however, Bodhi has been
> changed in the interim to behave better in this regard, so its current
> representation of the original sample URL is no longer a viable test.

I can't reproduce it either, even with a crafted html file.
Comment 8 Fedora End Of Life 2017-08-08 17:35:09 UTC 
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.