943985 - Platform/driver-specific SVG rendering hangs, 100% CPU and memory

Status: RESOLVED WORKSFORME

(Core :: SVG, defect)

Description

[Sean McNamara]

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Firefox/24.0 (Beta/Release)
Build ID: 20131112155850

Steps to reproduce:

The following minimal SVG file, when loaded in Firefox, causes Firefox to use 100% CPU persistently. On some systems, it also produces an ever-growing memory usage, which eventually either runs the process out of virtual address space, or runs the host system out of virtual memory.

There are platform/driver combinations where it occurs, and at least one where it does not occur.

The SVG is: 
<?xml version="1.0"?>
<svg xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://www.w3.org/2000/svg" xmlns:osb="http://www.openswatchbook.org/uri/2009/osb" xmlns:cc="http://creativecommons.org/ns#" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:dc="http://purl.org/dc/elements/1.1/" id="svg2" viewBox="0 0 858.5 854.82" version="1.1">
  <defs id="defs4">
    <filter id="filter3989-61" width="1.5" y="-.23" x="-.26" height="1.5" color-interpolation-filters="sRGB">
      <feDiffuseLighting id="feDiffuseLighting4025-31" result="result5" surfaceScale="16.48351669" diffuseConstant="1.29999995" kernelUnitLength="0.01">
        <feDistantLight id="feDistantLight4027-8" elevation="83" azimuth="260"/>
      </feDiffuseLighting>
    </filter>
  </defs>
  <g id="layer1" transform="translate(-78.069 -399.61)">
      <g id="g6521" transform="matrix(.37428 0 0 .37428 9.8169 1039.3)">
        <path id="path3135" filter="url(#filter3989-61)" d="m614.81 108.08c0 35.147-28.492 63.64-63.64 63.64-35.147 0-63.64-28.492-63.64-63.64 0-35.147 28.492-63.64 63.64-63.64 35.147 0 63.64 28.492 63.64 63.64z" fill="#f0eb7b" transform="matrix(1.2285 0 0 1.2285 -350.46 306.45)"/>
      </g>
    </g>
</svg>

This is a small snippet from the following source file: http://openclipart.org/people/GR8DAN/showbizframe.svg

The platforms on which it was tested:

Windows 7 32-bit, Nvidia NVS 300, graphics driver 8.17.12.5993 from 10/16/2010, AzureCanvas and AzureContent set to direct2d, running Firefox 24.1.1 ESR and Firefox 25.0.1: Can not reproduce the problem at all in either version of FF. Tried with both hardware acceleration enabled and disabled. This test determined that it is not the specific browser version of FF 25.0.1, because this system could not reproduce the issue using either FF 24.1.1 or 25.0.1.

The following systems could all reproduce the 100% CPU usage and at least 1 GB of memory usage out of Firefox, but depending on the specific host configuration, not all systems experienced OOM or virtual address space exhaustion symptoms:

All with Firefox 25.0.1:

Windows 8.1 with the latest Intel display driver for a Core i5 (Ivy Bridge) -- high memory/CPU usage, but Firefox continued to work (slowly).
Mac OS X 10.8 with the latest Mac display driver -- high memory/CPU, but Firefox continued to work (slowly).

Fedora 19 GNU/Linux with Nvidia 304.88 driver -- kernel OOM killer kicks in after long delay/lag.

More results available at https://docs.google.com/spreadsheet/ccc?key=0AnUk3SRcR-SJdHhEWnRZd0Z4T3VzSEpid1VKWkNEQ1E&usp=sharing


Actual results:

Please see the following:

http://superuser.com/q/681328/144607
and
http://chat.stackexchange.com/transcript/message/12376426#12376426


Expected results:

Doesn't crash, use 100% CPU, or eat undue amounts of RAM.

Comment 1

[Sean McNamara]

See here for an image that deliberately exacerbates the problem (I copied and pasted the offending lines 19 more times and changed the filter and def IDs): https://rawgithub.com/allquixotic/7682453/raw/0258eb0cef88e393cfd1f5ce30da25f5fb89c8dd/crash.svg -- for those who experience high memory usage but no crash when viewing the original image or the SSCCE, this one will, in all likelihood, overflow your virtual address space and crash your browser, unless you have a ridiculous amount of RAM and are running a 64-bit build of Firefox.

Comment 2

[Sudheesh Singanamalla (:ShellHacker)]

Confirmed high CPU memory usage. Opening the `crash.svg`[1] file made Firefox unresponsive.

Reproduced  on :
Firefox Nightly UX 28.0a1 (2013-11-28)
User Agent :Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:28.0) Gecko/20100101 Firefox/28.0

Processor  2.7 GHz Intel Core i7
Memory  16 GB 1600 MHz DDR3
Software  OS X 10.9

[1] https://rawgithub.com/allquixotic/7682453/raw/0258eb0cef88e393cfd1f5ce30da25f5fb89c8dd/crash.svg

Comment 3

[Sean McNamara]

Updating version to Trunk, because I experience very similar bad behavior (high CPU and memory usage) on Nightly on Windows 8.1.

Of note: On Alpha and Nightly, the CPU and memory usage will eventually settle down if you stay on the tab with the offending SVG for 15 or 20 seconds. Eventually all the metrics return to normal. But, then if you switch to a different tab and go back to the SVG, the process repeats, with high CPU/memory usage again, followed by low FPS and lag, followed by another eventual settling down. On FF 25, the high CPU/memory usage persists indefinitely, until killing the tab or Firefox itself.

Comment 4

[Sean McNamara]

Two people running separate hardware are unable to reproduce this problem on Firefox 32 and 34. Seems to be fixed.