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