495394 - possible memory leak when displaying large svg files

Status: RESOLVED WORKSFORME

(Core :: SVG, defect)

Description

[Steffen Banhardt]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.0.10) Gecko/2009042523 Ubuntu/9.04 (jaunty) Firefox/3.0.10
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.0.10) Gecko/2009042523 Ubuntu/9.04 (jaunty) Firefox/3.0.10

This bug is frum Ubuntu's launchpad, see link:

Some svg files make Firefox consume up all memory and crash. One example is the svg linked at http://en.wikipedia.org/wiki/File:Sun_and_VY_Canis_Majoris.svg, I tried to find, what part of this svg is responsible for that behaviour, a sample file is attached.

The file contains a path, which is a large, closed circle, made with cubic bezier:

d="M 800,500 C 800,700 600,900 400,900 C 200,900 0,700 0,500 C 0,300 200,100 400,100 C 600,100 800,300 800,500 z "

This is enlarged by a matrix:

transform="matrix(20,0,0,20,-3000,-14000)"

The whole thing has a feGaussianBlur filter on itself with stdDeviation="3.2"

The graphic loads if *one* of these is done:

* filter removed
* shrinked the path (e.g. everpoint divided by 100)
* "smaller" matrix

It is quite interesting to see, that the svg (as also the original file from wikipedia) loads without any problem in a background tab - firefox freezes only, when the tab is opened.

Reproducible: Always

Steps to Reproduce:
1. Open file
Actual Results:  
More and more memory is consumed, firefox crashes.

Expected Results:  
Firefox shows the svg.

Comment 1

[Steffen Banhardt]

Attachment: simple svg that crahes

Comment 2

[Robert Longson [:longsonr]]

Works for me with a current trunk build, although I'm testing on Windows rather than Linux.

Does a current trunk build still crash for you? If so can you follow the steps in https://developer.mozilla.org/En/How_to_get_a_stacktrace_for_a_bug_report or http://kb.mozillazine.org/Getting_a_stacktrace_with_gdb to get a stack trace?

Comment 3

[Robert Longson [:longsonr]]

Actually, never mind. 3.0.10 hangs on Windows too so some patch since then has fixed it.

Comment 4

[John Vivirito]

This bug should not have been closed 
Windows build is not the same as Linux 
this bug is marked as a Linux bug not windows
Please reopen this bug

Comment 5

[John Vivirito]

This bug should not have been closed 
Windows build is not the same as Linux 
this bug is marked as a Linux bug not windows
Please reopen this bug

Comment 6

[Robert Longson [:longsonr]]

The bug exists on Windows too on 3.0.x It does not exist on Windows with a current trunk build. Reopen it if you confirm that the current trunk still has a problem on Linux.

Comment 7

[Steffen Banhardt]

Can't reproduce anymore with 

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b4pre) Gecko/20090401 Ubuntu/9.04 (jaunty) Shiretoko/3.5b4pre

So it seems to be resolved and fixed

Comment 8

[Matthias Versen [:Matti]]

no patch in the bug = not fixed