Several SuperUser regulars are currently trying to narrow down the scope and cause of this issue. We are currently seeking willing volunteers to fill out the form here after performing the following test:
- Install or start a recent version of Firefox (say, 24.x or 25.x; beta would be interesting too).
- Watch memory and CPU usage using your platform's equivalent of the Windows Task Manager. You should have the appropriate task manager open before you open the link below.
- Save any unfinished work in your Firefox browser, as it may crash. We take no responsibility for any lost information.
- Open the following link in a new tab: http://openclipart.org/people/GR8DAN/showbizframe.svg
- Observe the changes in CPU and memory usage of the Firefox process before and after loading the image. If the difference between Firefox's memory usage before and after opening the above tab is very significant (1 GB or more), or if Firefox freezes/crashes, or if you see sustained high CPU usage, your system has the bug. Otherwise, you do not have the bug. In either case, fill out the form accordingly.
We are trying to narrow down the symptoms and cause in order to update a bug on the Mozilla bug tracker so that the Mozilla developers might resolve the problem. We are doing this specifically because this is potentially a wide-ranging, high-priority issue; any websites that allow image embedding could be vulnerable to a Denial of Service attack against a significant subset of users visiting the page, if this starts to be used maliciously.
Update 11/29/2013: The bug has been isolated to the following:
- It's platform-independent. The bug has been reproduced on Linux, Mac, and Windows.
- The problem has been reproduced with AMD, Intel, and Nvidia graphics cards.
- It only occurs on Firefox and derivatives. Chrome, IE, Opera are not impacted.
- The problem has been produced on Firefox 25.0.1, Firefox 26 Beta, Firefox 27 Alpha, and the Nightly build of the trunk as of 11/28/2013.
- Not all users are experiencing a Firefox crash or a system-wide Out of Memory (OOM) situation. This behavior appears limited to GNU/Linux systems with 4 GB of RAM or less.
- On Firefox 27 Alpha and Nightly, the behavior differs slightly from Firefox 25 and 26 Beta: on the newer two versions, high CPU and memory consumption will eventually settle down if you let the image load for an extended period of time (10 to 20 seconds on most systems). Once it's "settled", memory and CPU conditions return to normal. But on the older two releases, the CPU and memory conditions persist as long as you are switched to the tab with the offending image being rendered, or until you kill Firefox entirely, or close the tab.
- Almost all systems with recent graphics drivers can reproduce it. We only have one system on file that doesn't experience any symptoms whatsoever, and it's using an extremely old graphics driver (about 3 years). This indicates that it isn't any specific hardware, but rather, there is a bug in the very old driver that was used which, oddly enough, prevents the defective behavior from occurring.
I'm using Firefox firefox-25.0-3.fc19.x86_64 on Fedora 19 (kernel 3.11.9-200.fc19.x86_64). If I open this link using firefox, my system becomes unresponsive. Running
htop on a second monitor shows a massive spike in memory usage, my 3954 MB of RAM gets all used up immediately, then the swap gets slowly filled, one of the processor's usage goes up to 100%, then the system becomes unresponsive, the mouse becomes slow,
htop takes dozens of seconds to refresh, etc. If I kill the FF process everything goes back to normal.
Even if restarting FF in safe mode with plugins disabled the behavior is the same. I tried my coworker's machine and it has ~8000 MB RAM, the same happens (high memory usage and 1 processor reaches 100%), when it reaches ~4096 MB usage, a dialog pops up asking to kill firefox (maybe firefox is hardcoded to use only 4096 MB?).
What is causing it?
UPDATE: The issue arises when viewing this SVG.